https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117088
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jan Hubicka from comment #6)
> > void digits_2.isra (integer(kind=4) ISRA.6607)
> > {
> > integer(kind=4) ISRA.6607_927(D) = ISRA.6607;
> > ...
> > # RANGE [irange] integer(kind=4) [-2147483647, 8][10, +INF]
> > _494 = ISRA.6607_927(D) + 1;
> >
> > by the time VRP sees it, i think ISRA.6607_927(D) is the actual parameter?
> > if
> > you set SSA_NAME_RANGE_INFO (ISRA.6607_927(D)) to [1, +INF] or [1, 10] or
> > whatever, VRP will likely do some useful things.
> >
> > VRP can't figure out the non-negative part on its own as the fact that it is
> > always [1, INF] is not apparent from within the function. Someone has to
> > provide that info via the ssa-name passed as the parameter.
>
> I think [1,INF] should be determinable from ipa-prop, since we know that
> argument starts at 0 and increases by one for each recursive call. I
> suppose we are giving up propagating value ranges to avoid problems with
> "infinite depth" of the value range lattice?
There is no value_range lattice any longer as we do not iterate in the
traditional sense. We occasionally propagate updated values as we go through a
loop, but we do not iterate and bump values in the ways I think you are
referring to.
The PHI analysis part of ranger (which is still fairly simple and just provides
improvements to initial ranges) will look at values feeding PHIS and do some
of those kinds of projections. Ie
bb4::
x_1 = PHI <0(2), x_5(5)>
x_5 = x_1 + 1
if (x_5 < 20) goto bb4:
Rangers PHI analysis will determine x_1 has a starting range of [0, +INF] due
to the makeup of x_5 being related to x_1 in a predictable way. Ranger then
figures out based n the x_5 < 20 that the range is refined to [0,19]
Without PHI analysis we don't recognize there is a pattern and x_1 ends up with
a range of [-INF, 19]. It has its limitations of course, ranger makes no
attempt to do loop analysis, which is what this boils down to.
