Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener:
> On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker <ma.uec...@gmail.com> wrote:
> > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker <ma.uec...@gmail.com> wrote:
> > > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
...
> Consider
>
> int a[1024];
> void foo (volatile int *p, float *q)
> {
> for (int i = 0; i < 1024; ++i)
> {
> *p = 1;
> a[i] = *q;
> }
> }
>
> we happily apply invariant motion to the load from *q, making
> it cross the store to the volatile object at *p. Now, q might be
> NULL upon entry to the function and thus this transform
> would violate the volatile "I/O" constraint (since I/O is observable)
> and thus we will crash (which is UB) before doing the first I/O.
>
> That's an example I'd consider important for performance and
> also a case that shows that usually the compiler will have a
> very hard time proving UB cannot happen (as opposed to the
> usual stance where it can assume it doesn't).
I can see that the transformation in general is important,
but why is it important if the "volatile" is there?
I would assume that performance-sensitive code usually
does not volatile.
Or in other words, what is the purpose of volatile in
this example if not either I/O or to prevent such
optimizations?
> The case we run into sth similar is with use of uninitialized
> variables where proving some variable is initialized is nearly
> impossible (copy initialization from a variable that is not
> initialized is not initialization).
These are the C++ rules.
For C, an automatic variables which is not initialized and
(as long as the address is not taken), it is directly UB.
> We've mainly settled to the stance that only program termination
> is observable which means if we do not know that a function
> call will always return normally we have to avoid hoisting
> observable UB across such function call (and I/O routines
> usually fall into this category because they are not annotated
> as always returning).
Yes.
> 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.
Martin
> Richard.
>
> > Martin
> >
> > > > > > I am trying to figure out whether this is feasible.
> > > > >
> > > > > For PRE yes, you'd just need to include the observable stmts you
> > > > > care in the set of stmts that cause PRE to set BB_MAY_NOTRETURN.
> > > > > In general this is of course harder.
> > > >
> > > > What other passes would need to be checked?
> > >
> > > All that do code motion by design or by accident. The difficulty is
> > > that the resulting "wrong IL" is not wrong per se, just the difference is
> > > which is hard to write a checker for (well, in priciple you could copy the
> > > IL before passes and compare to the IL after)
> > >
> > > > And do you think there is any negative impact on
> > > > an important optimization (considering this affects
> > > > only volatile accesses)?
> > >
> > > Probably not. But then semantics of 'volatile' are very weak defined
> > > so I'd like
> > > to see a reference to a part of the standard that supports declaring this
> > > (and only this - the 'volatile' case) a bug.
> > >
> > > > > > > GCC assumes by default that divide is trappable but stores not
> > > > > > > are not
> > > > > > > observable. This is where -fnon-call-exceptions come into play.
> > > > > >
> > > > > > Ok, thanks! I will look at this!
> > > > > >
> > > > > > > In the second case, GCC assumes reducing trappable instructions
> > > > > > > are
> > > > > > > fine.
> > > > > >
> > > > > > -fnon-call-exceptions would treat trapping instructions
> > > > > > as defined (and trapping) instead of UB? This is
> > > > > > then probably even stronger than the requirement above.
> > > > >
> > > > > No, I don't think it turns UB into defined behavior. Some frontends
> > > > > might
> > > > > expect that to some extent. So even with -fnon-call-exceptions we'd
> > > > > happily do the re-ordering unless the exception is catched in the same
> > > > > function.
> > > >
> > > > Thanks,
> > > > Martin
> > > >
> > > > > > > Note I thought -fno-delete-dead-exceptions would fix the sink
> > > > > > > but it didn't.
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > >
