This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Isolate & simplify paths with undefined behaviour
- From: Jeff Law <law at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Tue, 22 Oct 2013 13:00:16 -0600
- Subject: Re: [RFC] Isolate & simplify paths with undefined behaviour
- Authentication-results: sourceware.org; auth=none
- References: <52616BFC dot 6010205 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1310182019300 dot 4203 at laptop-mg dot saclay dot inria dot fr> <52618D60 dot 9090101 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1310182151270 dot 4203 at laptop-mg dot saclay dot inria dot fr>
On 10/18/13 14:31, Marc Glisse wrote:
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.
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
Storing the VRP info might not actually help, since you need to know
starting from which statement the pointer is non-zero.
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
If we find the x->z use first in the immediate use iterator, we'll first
Then we see the x->y use and transform into
Which is exactly what we want.