Re: [RFC] tools/memory-model: Rule out OOTA

[Alan Stern]

On Wed, Jan 22, 2025 at 04:46:03AM +0100, Jonas Oberhauser wrote:
> > > > > Yes. Actually I wonder if you put this "all loads are volatile" restriction,
> > > > > can a globally analysing compiler still have any optimizations that a
> > > > > locally analysing compiler can not?
> > > > 
> > > > Yes, although whether they are pertinent is open to question.  For
> > > > example, a globally optimizing compiler may observe that no thread ever
> > > > reads the value of a particular shared variable and then eliminate that
> > > > variable.
> > > 
> > > Oh, I meant the "all atomic objects is volatile" restriction, not just the
> > > loads. In that case, all stores the object - even if never read - still need
> > > to be generated.
> > > 
> > > Are there still any optimizations?
> > 
> > Perhaps not any that affect shared variable accesses.  In a way, that
> > was the intention.
> 
> Yes, but it becomes a bit strange then to treat the "globally analyzing
> compiler" as a harder problem. You have made a globally analyzing compiler
> that can not globally analyze. I understand that makes the argument
> feasible, but I am not sure if this is how compilers really behave (or at
> least will still behave in the future).

There's still an important difference.  A globally optimizing compiler 
is allowed to generate different object code for a thread (containing 
the same source code) in different programs, depending on the source for 
the other threads.  A locally analyzing compiler is not allowed to do 
this; it will always generate the same object code for threads 
containing the same source code, regardless of what the rest of the 
program does.

Alan