I have one follow-up question: What is the reason that we have stronger semantics for stores by default (i.e. when not using -fallow-store-data-races) than for reads given that the standard would allow more freedom.
Only that for reads this is more difficult to have? Or other specific reasons why data races for stores are problematic? Martin Am Freitag, dem 28.02.2025 um 19:13 +0100 schrieb Martin Uecker: > 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 > >
