Re: C aggregate passing (Rust kernel policy)

Kent Overstreet
2025-02-27T18:13:47Z

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...