On 01/09/2017 02:36 AM, Richard Biener wrote:
a = 1;
<trigger non-call exception>
a = 2;
If "a" escapes such that its value can be queried in the exception handler,
then the exception handler would be able to observe the first store and thus
it should not be removed.
Yes, and it won't as long as the EH is thrown internally (and thus we have
a CFG reflecting it). When it's only externally catched we lose of course...
We'd need an Ada testcase to actually show behavior that is not conforming
to an existing language specification though.
I'm not versed enough in Ada to even attempt to pull together a testcase
for this.
I suspect we have a similar issue in C++ for sth like
void __attribute__((const)) foo () { throw; }
int x;
void bar ()
{
x = 1;
foo ();
x = 2;
}
where foo is const but not nothrow.
I wouldn't be surprised if there's other problems with const functions
that can throw.
We also have to be cognizant of systems where there is memory mapped at
location 0. When that is true, we must check pt.null and honor it, even if
it pessimizes code.
With -fno-delete-null-pointer-checks (that's what such systems set) PTA computes
0 as "nonlocal" and thus it won't be a singleton points-to solution.
Ah, good.
For
int foo (int *p, int b)
{
int *q;
int i = 1;
if (b)
q = &i;
else
q = (void *)0;
*q = 2;
i = 3;
return *q;
}
So on a system where *0 is a valid memory address, *q = 2 does not make
anything dead, nor does i = 3 unless we were to isolate the THEN/ELSE
blocks.
On a system where *0 traps, there is no way to observe the value of "i" in
the handler. Thus i = 1 is a dead store. I believe we must keep the *q = 2
store because it can trigger a signal/exception which is itself an
observable side effect? Right?
But writing to 0 invokes undefined behavior which we have no obligation to
preserve (unless we make it well-defined with -fnon-call-exceptions -fexceptions
as a GCC extension).
It may invoke undefined behavior, but to date we have explicitly chosen
to preserve the *0 = <something> to trigger a fault via the virtual
memory system. We kicked this around extensively in Nov 2013 with the
introduction of isolation of erroneous paths.
I think part of what pushed us that direction was that a program could
catch the signal related to the NULL dereference, then do something
sensible in the handler. That also happens to match what the Go
language requires.
we remove all stores but the last store to i and the load from q (but we
don't
replace q with &i here, a missed optimization if removing the other stores
is
valid).
But if we remove the *q = 2 store, we remove an observable side effect, the
trap/exception itself if we reach that statement via the ELSE path.
As said above - I don't think we have to care for C/C++ w/o
-fnon-call-exceptions.
So in the immediate term I propose we conditionalize the pt.null check
on non-call exceptions. THen I'll look more closely at the example
above and see what we can reasonably do there.
jeff
