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 >> <[email protected]> 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
