Thread (121 messages) 121 messages, 13 authors, 2021-09-24

Re: [RFC] LKMM: Add volatile_if()

From: Peter Zijlstra <peterz@infradead.org>
Date: 2021-06-04 16:37:52
Also in: linux-arch, lkml

On Fri, Jun 04, 2021 at 09:30:01AM -0700, Linus Torvalds wrote:
On Fri, Jun 4, 2021 at 3:12 AM Peter Zijlstra [off-list ref] wrote:
quoted
I've converted most architectures we care about, and the rest will get
an extra smp_mb() by means of the 'generic' fallback implementation (for
now).
Why is "volatile_if()" not just

       #define barier_true() ({ barrier(); 1; })

       #define volatile_if(x) if ((x) && barrier_true())

because that should essentially cause the same thing - the compiler
should be *forced* to create one conditional branch (because "barrier"
is an asm that can't be done on the false side, so it can't do it with
arithmetic or other games), and after that we're done.

No need for per-architecture "asm goto" games. No new memory barriers.
No actual new code generation (except for the empty asm volatile that
is a barrier).
Because we weren't sure compilers weren't still allowed to optimize the
branch away. If compiler folks can guarantee us your thing (along with
maybe the BUILD_BUG_ON(__builtin_constant_p(cond)) thing) always shall
generate a conditional branch instruction, then Yay!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help