Re: [PATCH hazptr 2/4] compiler.h: Introduce ptr_eq() to preserve address dependency

[Mathieu Desnoyers]

On 2026-09-29 11:16, Linus Torvalds wrote:
> On Tue, 29 Sept 2026 at 08:04, Mathieu Desnoyers
> <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
> > I agree that doing it in asm would generate better code. Also, I've
> > been told that clang now preserves the address dependency in this
> > scenario, so perhaps we'd want to use preprocessor conditionals to
> > select how to implement ptr_eq based on:
> >
> > - architecture (allowing asm implementation overrides),
> > - compiler (e.g. if compiler is clang >= version X, just do a plain
> >     comparison). Likewise for gcc if it ever decides to fix this
> >     behavior.
> >
> > I think this "hide var" hack is a fallback which can be used as a
> > starting point, and then we can specialize based on architecture and
> > compiler.
> >
> > Or do you prefer this in a different order ?
>
> Oh, if there's some sane way to tell that the compiler already honors
> address dependencies, then that should be done first and the whole
> thing should just become a simple
>
>   (a) == (b)
>
> for that situation - allowing the compiler then the freedom to do
> whatever (which can involve not using a register at all, but a compare
> to memory, or whatever - the compiler might have reasons to avoid the
> 'cmp' and use another sequence entirely)

For the records, here is the relevant compiler discussion:

https://github.com/llvm/llvm-project/issues/34577

and it seems like they still have unfixed scenarios,
which may or may not affect the hazptr use-case:

https://github.com/llvm/llvm-project/issues/220206

Considering this, I would not be inclined to jump to the conclusion
that using the compiler compare for hazptr acquire load/test/reload
is safe today without a careful analysis.

> Then a "if we have an architecture fallback".
>
> And then that OPTIMIZER_HIDE_VAR() thing as a last fallback.

OK,

Thanks!

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com