https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117088
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jan Hubicka from comment #3)
> > digits_2.isra (1);
> >
> > so we at least know row is [1, +INF] since the add is signed.
> >
> > We might be able to use a SCEV-like range computation for recursive cases
> > like
> > this, then being able to compute [2, 8] for the recursion invocation. Not
> > sure whether doing this in local VRP is possible and how much of help symtab
> > is here (single caller).
>
> ipa-prop already understands that the recursion depth is bounded
> by 10 for cloning reasons, so perhaps this can be turned to value range
> easily?
>
> Honza
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.
_494 will share the lower bound (well, +1) of whatever ISRA.6607_927(D) has.
It currently has no value, so it is VARYING as far as VRP known. which is why
_494 has a lower bound of -INF+1. It also appears to be in a loop with the
condition being _494 != 9 or something related like that.
Its never been clear ot me why we still change loop branches to use !=. We turn
for (int y = 0 ; y < 10; y++)
b[y] = x;
into
if (y_1 != 10)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
and as a result, range analysis only picks up that y_1 is not 10. whereas if
that had remained
if (y_1 < 10)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
we'd at least have picked up y_1 is [-INF, 9] at in BB3 instead of [-INF,9[11,
+INF]
Instead, it has to depend on loop analysis to find values that could just be
apparent.
