Re: C aggregate passing (Rust kernel policy)

[Kent Overstreet]

On Thu, Feb 27, 2025 at 09:35:10AM -0800, Paul E. McKenney wrote:
> On Thu, Feb 27, 2025 at 09:29:49AM -0500, Steven Rostedt wrote:
> > On Thu, 27 Feb 2025 07:56:47 +0100
> > Martin Uecker <uecker@xxxxxxxxx> wrote:
> > 
> > > Observable is I/O and volatile accesses.  These are things considered
> > > observable from the outside of a process and the only things an
> > > optimizer has to preserve.  
> > > 
> > > Visibility is related to when stores are visible to other threads of
> > > the same process. But this is just an internal concept to give
> > > evaluation of expressions semantics in a multi-threaded 
> > > program when objects are accessed from different threads. But 
> > > the compiler is free to change any aspect of it, as  long as the 
> > > observable behavior stays the same.
> > > 
> > > In practice the difference is not so big for a traditional
> > > optimizer that only has a limited local view and where
> > > "another thread" is basically part of the "outside world".
> > 
> > So basically you are saying that if the compiler has access to the entire
> > program (sees the use cases for variables in all threads) that it can
> > determine what is visible to other threads and what is not, and optimize
> > accordingly?
> > 
> > Like LTO in the kernel?
> 
> LTO is a small step in that direction.  In the most extreme case, the
> compiler simply takes a quick glance at the code and the input data and
> oracularly generates the output.
> 
> Which is why my arguments against duplicating atomic loads have been
> based on examples where doing so breaks basic arithmetic.  :-/

Please tell me that wasn't something that seriously needed to be said...