[RFC] Isolate & simplify paths with undefined behaviour

Jeff Law law@redhat.com
Tue Oct 22 19:12:00 GMT 2013


On 10/18/13 14:31, Marc Glisse wrote:
> On Fri, 18 Oct 2013, Jeff Law wrote:
>
>> On 10/18/13 12:47, Marc Glisse wrote:
>>> * 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.
>> I'm not sure what can really be shared here -- this patch searches for
>> PHIs where one or more of the args is a NULL pointer.  The NULL
>> pointer will be explicit in the PHI arg.
>
> But once you have that pointer defined by a PHI containing a zero, you
> look at all its uses, trying to find one that proves the pointer is
> non-zero (only dereferences for now, but you have a comment about the
> non-null attribute). And infer_nonnull_range precisely says whether a
> statement proves that a pointer is non-zero (well, there may be a few
> subtle differences, and some tests might need to move between
> infer_value_range and infer_nonnull_range). I am just talking of
> replacing 20 lines of code with a function call, not a huge sharing I
> agree...
>
> Storing the VRP info might not actually help, since you need to know
> starting from which statement the pointer is non-zero.
So I was poking at this a bit.  It's trival to use infer_nonnull_range 
and to teach infer_nonnull_range to use the returns_nonnull attribute to 
pick up that return x in an appropriately decorated function implies 
that x is non-null.

We'll need a better place to shove infer_nonnull_range so that it's 
available to both users.

I also looked at having VRP use the returns_nonnull to tighten ranges in 
the current function (when it's appropriately decorated).  However, 
that's a bit more problematical.  By the time we process the return 
statement, we've likely already taken the return value's range to 
VARYING.   Going back down the lattice (to ~[0, 0]) is generally 
considered bad.  Given how rarely I expect this to help, I'm dropping 
this part of the floor.


The hack I had to avoid processing a block multiple times if a single 
SSA_NAME has multiple uses in the block was totally unnecessary.  All 
the right things happen if that hack gets removed and isolate_path is 
slightly adjusted.  So if we have X that we've determined as a NULL 
value on some path, given a block like

x->y =
blah blah
x->z =
fu bar


If we find the x->z use first in the immediate use iterator, we'll first 
transform into
x->y =
blah blah
trap

Then we see the x->y use and transform into
trap


Which is exactly what we want.



jeff



More information about the Gcc-patches mailing list