On Fri, 18 Oct 2013, Jeff Law wrote:
Back in 2011 I wrote code to detect cases when traversing a particular path
could be proven to trigger undefined behaviour (such as a null pointer
dereference). That original patch would find the control dependent edges
leading to the dereference and eliminate those edges. The result being those
paths with undefined behaviour simply vanished.
The problem with that implementation is there could have been observable side
effects on those paths prior to triggering the undefined behaviour.
Maybe a new -fretroactive-undefined-behavior? (for later, obviously)
At that time I speculated we could isolate the path (via block copying) with
undefined behaviour. On the duplicate path we'd replace the undefined
behaviour with a trap and remove only the outgoing edges. That would still
preserve any visible side effects on the undefined path up to the undefined
behaviour and we still often get to simplify the main path, though not as
much as the original version from 2011.
That's precisely what this patch does. When we have a PHI which feeds a
memory dereference in the same block as the PHI and one (or more) of the PHI
args is NULL we duplicate the block, redirect incoming edges with the NULL
PHI args to the duplicate and change the statement with the memory
dereference to a trap.
Cool. As a new pass doing something quite clear, I am trying to read it to
learn, and have a couple minor comments:
* should cfg_altered be static (or a member of the pass class)?
* tree-vrp has a function infer_nonnull_range, do you think we could share
it? We now store the VRP ranges for integers, but not for pointers. If we
did (or maybe just a non-null bit), the pass could just test that bit on
the variable found in the PHI.
--
Marc Glisse
