Re: [RFC] LKMM: Add volatile_if()

[Paul E. McKenney]

On Sun, Jun 06, 2021 at 06:36:51AM -0500, Segher Boessenkool wrote:
> On Fri, Jun 04, 2021 at 01:40:42PM -0700, Paul E. McKenney wrote:
> > 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.
> 
> This was about the syntax "volatile if", not about the concept, let's
> call that "volatile_if".  And no, it was not me who brought this up :-)

I agree that it is likely that the syntax "volatile if" would be at best
a very reluctantly acquired taste among most of the committee.  But some
might point to the evolving semantics of "auto" as a counter-example,
to say nothing of the celebrated spaceship operator.  Me, I am not
all that worried about the exact syntax.

> > > > 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.
> 
> Oh definitely.  But there is nothing the compiler can do about most
> cases of undefined behaviour: it cannot detect it, and there is no way
> it *can* be handled sanely.  Take for example dereferencing a pointer
> that does not point to an object.

Almost.

The compiler's use of provenance allows detection in some cases.
For a stupid example, please see https://godbolt.org/z/z9cWvqdhE.

Less stupidly, this sort of thing can be quite annoying to people trying
to use ABA-tolerant concurrent algorithms.  See for example P1726R4
[1] (update in progress) and for an even more controversial proposal,
P2188R1 [2].  The Lifo Singly Linked Push algorithm described beginning
on page 14 of [1] is a simple example of an ABA-tolerant algorithm that
was already in use when I first programmed a computer.  ;-)

							Thanx, Paul

[1]	http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1726r4.pdf
[2]	http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2188r1.html