On Fri, Jun 04, 2021 at 12:18:43PM -0700, Linus Torvalds wrote: > On Fri, Jun 4, 2021 at 12:09 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Again, semantics do matter, and I don't see how the compiler could > > actually break the fundamental issue of "load->conditional->store is a > > fundamental ordering even without memory barriers because of basic > > causality", because you can't just arbitrarily generate speculative > > stores that would be visible to others. > > This, after all, is why we trust that the *hardware* can't do it. > > Even if the hardware mis-speculates and goes down the wrong branch, > and speculatively does the store when it shouldn't have, we don't > care: we know that such a speculative store can not possibly become > semantically visible (*) to other threads. > > For all the same reasons, I don't see how a compiler can violate > causal ordering of the code (assuming, again, that the test is > _meaningful_ - if we write nonsensical code, that's a different > issue). I am probably missing your point, but something like this: if (READ_ONCE(x)) y = 42; else y = 1729; Can in theory be transformed into something like this: y = 1729; if (READ_ONCE(x)) y = 42; The usual way to prevent it is to use WRITE_ONCE(). Fortunately, register sets are large, and gcc manages to do a single store and use only %eax. Thanx, Paul > If we have compilers that create speculative stores that are visible > to other threads, we need to fix them. > > Linus > > (*) By "semantically visible" I intend to avoid the whole timing/cache > pattern kind of non-semantic visibility that is all about the spectre > leakage kind of things.