Am Freitag, dem 28.02.2025 um 08:18 +0100 schrieb Richard Biener via Gcc: > On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker <uec...@tugraz.at> wrote: > > > > > > Hi all, > > > > one area where the Linux kernel people are unhappy with C's > > memory model is where they now have to use the READ_ONCE, > > WRITE_ONCE macros. These are cases where they do not want > > a compiler to duplicate a load, e.g. to reload a value > > later because registers were not available to cache it. > > The RA could do this as part of re-materialization to > avoid a spill-reload and I think this would be sensible. > > > Or similar, where a compiler produces two writes to > > the same object where the source has only one or > > invents a write where none existed, e.g. by turning > > a conditional write after a read in an unconditional > > one. > > That should be covered by -fno-allow-store-data-races > There might be the assumption that automatic variables > that have their address not taken are not subject to > store data races, and I have a hard time thinking of a > reason to want READ_ONCE or WRITE_ONCE for such. > > > General, it seems compilers currently do not do this. > > Yes, because it's a de-optimization. But for example > the partial PRE optimization can introduce a read to > a program path where it wasn't read to remove a > redundancy on another path that looks more performance > critical. Similarly a sinking transform could do the very > same to a store (but see above for -fallow-store-data-races). > > > One could alreay use volatile and then the C standard > > would guarantee that there are exactly as many accesses > > as the source code implies, but this is too strong, > > because combining multiple reads into one and caching > > the value or dead store elimination would still be ok. > > volatile is what gives you the guarantee for reads at > the moment. > > > The question is whether there are cases where GCC (or > > C compilers in general) do such things? Or if not, > > where this would be desirable? In other words: > > Would it be a ok to strengthen the requirements > > here? > > We have volatile, I don't see a good reason to invent > something new here, esp. that we have this guarantee > for stores anyway and that for reads it's going to be > quite difficult to implement that guarantee.
Thank you! This is very helpful information. Martin
