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

["Gary Guo" <gary@garyguo.net>]

On Tue Sep 29, 2026 at 4:42 PM BST, Mathieu Desnoyers wrote:
> On 2026-09-29 11:16, Linus Torvalds wrote:
>> On Tue, 29 Sept 2026 at 08:04, Mathieu Desnoyers
>> <mathieu.desnoyers@efficios.com> 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.

Out of the existing cases I think the only problematic one for hazptr is the
comparison against costant global. Which isn't going to be a problem for users
that don't depend on a fixed adress.

But it might be a problem for the lockdep case.

If we use inline asm for ptr_eq I think there's very little optimization
potentials left for compilers, so I think unconditionally using asm would be
fine.

Best,
Gary