Re: C aggregate passing (Rust kernel policy)

["Paul E. McKenney" <paulmck@kernel.org>]

On Thu, Feb 27, 2025 at 01:13:40PM -0500, Kent Overstreet wrote:
> 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@tugraz.at> 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...

You are really asking me to lie to you?  ;-)

							Thanx, Paul