https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> --- risk/churn. > > At least that is what I'M currently trying. would this be OK? > > Let's see what you can come up with. > (which is why I really did like to have the old EVRP since conceptually > it's easy to have a very fine-grained "context") > > Practically I think it's OK for true on-demand users to have the > less precise per-BB non-NULL data. But the value-range passes > should really be able to keep a precise per-stmt "context". > > Did I say I liked the old EVRP way of doing things? ;) Intention has always been to introduce a range_after_stmt to the API for side-effects, which would merge some aspects of the way EVRP did things. I have a patchset which I will submit shortly.. once everything passes mustard. Its actually not that significant of a change. Ranger currently tracks non-null for an ssa-name in blocks with a single bit. I change that to 2 bits so we can tell if all uses in the block have the non-null property, or if there are some uses which do not have the property. range-on-entry is changed to only check the dominators, and range-of-expr is changed to only apply the non-null property if the entire block has only uses with the non-null property. After trying to simply/fold each statement in the domwalk, I now check if the statement sets the non-null property. If so, then mark this block as non-null throughout, and any further queries through range_of_expr within this block will now pick up the non-null property. This allows us the flexibility of EVRPs granular walk, while remaining conservative with any on demand clients. This also solves the problematic testcase I showed earlier, producing the desired: _1 = p_3(D) == 0B; _2 = (int) _1; h (_2); foo (p_3(D)); return; Anyway, patch coming soon. I believe it to be low risk as the changes are all localized, and results should always be more conservative with the additonal granularity.
