Messages in this thread | | | Date | Tue, 6 Oct 2020 16:43:02 +0200 | From | Peter Zijlstra <> | Subject | Re: Control Dependencies vs C Compilers |
| |
On Tue, Oct 06, 2020 at 10:23:24AM -0400, stern@rowland.harvard.edu wrote: > On Tue, Oct 06, 2020 at 03:31:15PM +0200, Peter Zijlstra wrote:
> > Only if we get the compiler people on board and have them provide means > > are we guaranteed safe from the optimizer. Otherwise we'll just keep > > playing whack-a-mole with fancy new optimization techniques. And given > > how horridly painful it is to debug memory ordering problems, I feel it > > is best to make sure we're not going to have to more than necessary. > > Given that you would have to add a compiler annotation, isn't it just as > easy to use READ_ONCE and WRITE_ONCE? > > Or are you worried that even with READ_ONCE and WRITE_ONCE, the compiler > might still somehow defeat the control dependency?
Yes.
Also, not all instances actually have the WRITE_ONCE() on. The one in the perf ringbuffer for example uses local_read() for the load (which is basically READ_ONCE()), but doesn't have WRITE_ONCE() on the inside.
Also, afaiu WRITE_ONCE() also doesn't stop the compiler from lifting it if it thinks it can get away with it -- memory-barriers.txt has examples.
And then there's the case where the common branch has a store, I know ARM64 ARM isn't clear on that, but I'm thinking any actual hardware will still have to respect it, and it's a matter of 'fixing' the ARM.
Mostly I just want the compiler people to say they'll guarantee the behaviour if we do 'X'. If 'X' happens to be 'any dynamic branch headed by a volatile load' that's fine by me.
If they want a new keyword or attribute, that's also fine. But I want to have the compiler people tell me what they want and guarantee they'll not come and wreck things.
| |