RFA: New pass to delete unexecutable paths in the CFG

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/07/11 15:25, Richard Guenther wrote:
> 
> Indeed.  We'd have to tell people that they cannot catch *(void *)0
> = 0 with a SIGSEGV signal handler unless they compile with some
> magic flag. Thus, the question is whether we want to optimize
> things in a way that are non-obvious to people viewing things from
> a POSIX point of view rather than a C standard conforming issue.
Agreed.  The path I'd started going down was a flag like
"-fassume-null-dereference-faults-and-is-uncatchable" or something
like that.  -fdelete-null-pointer-checks  would be subsumed by the new
flag.


> 
> 
> But what we could do by default is transform such stores to a trap 
> representation, or at least making the feeding stmts dead by
> changing the stored value and the address to a constant (thus, even
> preserve the trap kind).  fold_stmt could change the stored value
> if the address is literal zero, and all passes that know it is zero
> should propagate it anyway.  That wouldn't remove the outgoing edge
> from the store of course, cfgcleanup could be teached to do that
> though (and we could invent a trap kind argument to
> __builtin_trap).
More correctly, we'd wipe the path from the control edge to the *0
statement and remove the out edges from the block with the *0.  Then
just leave the *0 or a __builtin_trap.

We'd leave the control edge itself leading to the *0/trap.  That
allows us to get most of the space savings optimization as well as
most of the secondary benefits.  The programmer could still catch the
trapping signal.

That doesn't work in the case of the implied dereference via  NULL PHI
arg.  For that case we'd have to copy the block with the PHI, the
incoming edges would be partitioned into those implying a null
dereference vs those not implying a null dereference.  Effectively
this isolates the path with the implied NULL dereference and turns it
into an explicit NULL dereference and we could optimize as noted above.

So the question is do we want to proceed with any of this work?  If so
I can update the patch, if not I'll go back to my warning work :-)

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOuYdZAAoJEBRtltQi2kC7z8oH/RVnZ03u2E20D2IbH++f0tiD
0StUVXlgtGGZHtY3jUupFzsQSSoyYtZhbgsVCCIm2Vu56t8jnb1YeWh8U4LVzsnA
SifQo9txI5rp9NECahsqHUMxYFOlFDXVfIzc2c0Fq/RTZ5dRCVCYgHTRODHB1qcJ
tXw4ckT0YOTEatGJsGt7QJtmEcjao71QV6UENbnzK6OIr7pD+hvFD0zUk7cZCyjW
eIH3uy075qt06o3tCyDq0KU6sz8HqHZu9r9WFKx7pi2Tyqxysxps4KiH/X9ruz74
w+0fVIHnqUbszMjqsOSls+Qu/DvhKVACIwGyStcgMyHyTcgrnyy7WkGzkWgcOQk=
=mSLN
-----END PGP SIGNATURE-----