https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 31 Jan 2022, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288 > > --- Comment #7 from Andrew Macleod <amacleod at redhat dot com> --- > I'm contemplating the situation. The trick is to find something with minimal > change that is functionally acceptable. I think the goal for this release > would be to continue to get vrp111.c, and simply not get it in the problematic > case.. ie, if the first use in the block is unknown and then LATER in the > block we figure out that it is non-null, we will miss that case through-out > the block for now. > > Effectively: if no dominator block contains non-null then whatever the first > use in a block determines will apply to the whole block, for the duration of > the block.. but upon exit to the block, if it was non-null anywhere, then all > following blocks get that knowledge. > > I think this could be done reasonably efficiently with a minimum of > risk/churn. > At least that is what I'M currently trying. would this be OK? Let's see what you can come up with. For ranges derived from stmts that are not the last in a BB (in which case they apply to outgoing edges) you have to strictly adhere to the notion that you have ranges incoming into a stmt and ranges outgoing so each stmt is the source of new ranges. That applies to divisions (nonzero divisor) or shifts (no out of range shift operand). But you may not apply the range to all stmts of a block (including the stmt producing the range itself). With the old EVRP scheme I failed to nicely support deriving non-zero divisor ranges for this reason for example. That makes it complicated to handle in an on-demand fashion of course since you'd need a per stmt cache that is much more difficult to manage and look up. (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? ;)
