Re: [RFC] LKMM: Add volatile_if()

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

On Fri, Jun 04, 2021 at 02:53:01PM -0500, Segher Boessenkool wrote:
> On Fri, Jun 04, 2021 at 11:55:26AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:
> > > My point is that you ask compiler developers to paint themselves into a
> > > corner if you ask them to change such fundamental C syntax.
> > 
> > Once we have some experience with a language extension, the official
> > syntax for a standardized version of that extension can be bikeshedded.
> > Committees being what they are, what we use in the meantime will
> > definitely not be what is chosen, so there is not a whole lot of point
> > in worrying about the exact syntax in the meantime.  ;-)
> 
> I am only saying that it is unlikely any compiler that is used in
> production will want to experiment with "volatile if".

That unfortunately matches my experience over quite a few years.  But if
something can be implemented using existing extensions, the conversations
often get easier.  Especially given many more people are now familiar
with concurrency.

> > > I would love to see something that meshes well with the rest of C.  But
> > > there is no 1-1 translation from C code to machine code (not in either
> > > direction), so anything that more or less depends on that will always
> > > be awkward.  If you can actually express the dependency in your source
> > > code that will get us 95% to where we want to be.
> 
> ^^^
> 
> > > > Data dependencies, control dependencies and address dependencies, C
> > > > doesn't really like them, we rely on them. It would be awesome if we can
> > > > fix this.
> > > 
> > > Yes.  The problem is that C is a high-level language.  All C semantics
> > > are expressed on a an "as-if" level, never as "do this, then that" --
> > > well, of course that *is* what it says, it's an imperative language just
> > > like most, but that is just how you *think* about things on a conceptual
> > > level, there is nothing that says the machine code has to do the same
> > > thing in the same order as you wrote!
> > 
> > Which is exactly why these conversations are often difficult.  There is
> > a tension between pushing the as-if rule as far as possible within the
> > compiler on the one hand and allowing developers to write code that does
> > what is needed on the other.  ;-)
> 
> There is a tension between what users expect from the compiler and what
> actually is promised.  The compiler is not pushing the as-if rule any
> further than it always has: it just becomes better at optimising over
> time.  The as-if rule is and always has been absolute.

Heh!  The fact that the compiler has become better at optimizing
over time is exactly what has been pushing the as-if rule further.

The underlying problem is that it is often impossible to write large
applications (such as the Linux kernel) completely within the confines of
the standard.  Thus, most large applications, and especially concurrent
applications, are vulnerable to either the compiler becoming better
at optimizing or compilers pushing the as-if rule, however you want to
say it.

> What is needed to get any progress is for user expectations to be
> feasible and not contradict existing requirements.  See "^^^" above.

Or additional requirements need to be accepted by the various compilation
powers that be.  Failing to acknowledge valid new user expectations is
after all an excellent path to obsolescence.

							Thanx, Paul