Re: reordering of trapping operations and volatile

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Sat, 15 Jan 2022, 09:00 Martin Uecker, <ma.uecker@gmail.com> wrote:

> Am Freitag, den 14.01.2022, 19:54 +0000 schrieb Jonathan Wakely:
> > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, <gcc@gcc.gnu.org>
> wrote:
> >
> > > Hello,
> > >
> > > On Thu, 13 Jan 2022, Martin Uecker wrote:
> > >
> > > > > > >  Handling all volatile accesses in the very same way would be
> > > > > > > possible but quite some work I don't see much value in.
> > > > > >
> > > > > > I see some value.
> > > > > >
> > > > > > But an alternative could be to remove volatile
> > > > > > from the observable behavior in the standard
> > > > > > or make it implementation-defined whether it
> > > > > > is observable or not.
> > > > >
> > > > > But you are actually arguing for making UB be observable
> > > >
> > > > No, I am arguing for UB not to have the power
> > > > to go back in time and change previous defined
> > > > observable behavior.
> > >
> > > But right now that's equivalent to making it observable,
> > > because we don't have any other terms than observable or
> > > undefined.  As aluded to later you would have to
> > > introduce a new concept, something pseudo-observable,
> > > which you then started doing.  So, see below.
> > >
> > > > > That's
> > > > > much different from making volatile not be
> > > > > observable anymore (which  obviously would
> > > > > be a bad idea), and is also much harder to
> > > >
> > > > I tend to agree that volatile should be
> > > > considered observable. But volatile is
> > > > a bit implementation-defined anyway, so this
> > > > would be a compromise so that implementations
> > > > do not have to make all the implied changes
> > > > if we revise the meaning of UB.
> > >
> > > Using volatile accesses for memory mapped IO is a much stronger
> use-case
> > > than your wish of using volatile accesses to block moving of UB as a
> > > debugging aid, and the former absolutely needs some guarantees, so I
> don't
> > > think it would be a compromise at all.  Mkaing volatile not be
> observable
> > > would break the C language.
> > >
> > > > > Well, what you _actually_ want is an implied
> > > > > dependency between some UB and volatile accesses
> > > > > (and _only_ those, not e.g. with other UB), and the
> > > > > difficulty now is to define "some" and to create
> > > > > the dependency without making that specific UB
> > > > > to be properly observable.
> > > >
> > > > Yes, this is what I actually want.
> > > >
> > > > >  I think to define this
> > > > > all rigorously seems futile (you need a new
> > > > > category between observable  and UB), so it comes
> > > > > down to compiler QoI on a case by case basis.
> > > >
> > > > We would simply change UB to mean "arbitrary
> > > > behavior at the point of time the erraneous
> > > > construct is encountered at run-time"  and
> > > > not "the complete program is invalid all
> > > > together". I see no problem in specifying this
> > > > (even in a formally precise way)
> > >
> > > First you need to define "point in time", a concept which doesn't exist
> > > yet in C.  The obvious choice is of course observable behaviour in the
> > > execution environment and its specified ordering from the abstract
> > > machine, as clarified via sequence points.  With that your "at the
> point
> > > in time" becomes something like "after all side effects of previous
> > > sequence point, but strictly before all side effects of next sequence
> > > point".
> > >
> > > But doing that would have very far reaching consequences, as already
> > > stated in this thread.  The above would basically make undefined
> behaviour
> > > be reliably countable, and all implementations would need to produce
> the
> > > same counts of UB.  That in turn disables many code movement and
> > > commonization transformations, e.g. this:
> > >
> > > int a = ..., b = ...;
> > > int x = a + b;
> > > int y = a + b;
> > >
> > > can't be transformed into "y = x = a + b" anymore, because the addition
> > > _might_ overflow, and if it does you have two UBs originally but would
> > > have one UB after.  I know that you don't want to inhibit this or
> similar
> > > transformations, but that would be the result of making UB countable,
> > > which is the result of forcing UB to happen at specific points in time.
> > > So, I continue to see problems in precisely specifying what you want,
> _but
> > > not more_.
> > >
> > > I think all models in which you order the happening of UB with respect
> to
> > > existing side effects (per abstract machine, so it includes
> modification
> > > of objects!) have this same problem, it always becomes a side effect
> > > itself (one where you don't specify what actually happens, but a side
> > > effect nontheless) and hence becomes observable.
> > >
> >
> > The C++ committee is currently considering this paper:
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1494r2.html
> >
> > I think this explicit barrier-like solution is better than trying to use
> > volatile accesses to achieve something similar.
>
> Can you explain why?  To me a solution which would make
> it "just work" (and also fixes existing code) seems
> better than letting programmers jump through even
> more hoops, especially if only difficult corner
> cases are affected.
>

Because it interferes with existing optimisations. An explicit checkpoint
has a clear meaning. Using every volatile access that way will hurt
performance of code that doesn't require that behaviour for correctness.




>
> Martin
>
>
> >
> >
> > >
> > >
>
>