On Fri, Jun 04, 2021 at 11:43:59AM +0100, Will Deacon wrote: > On Fri, Jun 04, 2021 at 12:12:07PM +0200, Peter Zijlstra wrote: > > With optimizing compilers becoming more and more agressive and C so far > > refusing to acknowledge the concept of control-dependencies even while > > we keep growing the amount of reliance on them, things will eventually > > come apart. > > > > There have been talks with toolchain people on how to resolve this; one > > suggestion was allowing the volatile qualifier on branch statements like > > 'if', but so far no actual compiler has made any progress on this. > > > > Rather than waiting any longer, provide our own construct based on that > > suggestion. The idea is by Alan Stern and refined by Paul and myself. > > > > Code generation is sub-optimal (for the weak architectures) since we're > > forced to convert the condition into another and use a fixed conditional > > branch instruction, but shouldn't be too bad. > > > > Usage of volatile_if requires the @cond to be headed by a volatile load > > (READ_ONCE() / atomic_read() etc..) such that the compiler is forced to > > emit the load and the branch emitted will have the required > > data-dependency. Furthermore, volatile_if() is a compiler barrier, which > > should prohibit the compiler from lifting anything out of the selection > > statement. > > When building with LTO on arm64, we already upgrade READ_ONCE() to an RCpc > acquire. In this case, it would be really good to avoid having the dummy > conditional branch somehow, but I can't see a good way to achieve that. Thinking more on this, an alternative angle would be having READ_ONCE_CTRL() instead of volatile_if. That would then expand (on arm64) to either something like: LDR X0, [X1] CBNZ X0, 1f // Dummy ctrl 1: or, with LTO: LDAPR X0, [X1] // RCpc and we'd avoid the redundancy. Will
