https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #25 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Adding some notes here as I work through this PR...
Even with floating aware VRP, we won't be able to do much because SCEV (which
ranger and VRP use) does not work with non-integers.
At EVRP time we see:
double BG_SplineLength ()
{
double i;
double lastPoint;
<bb 2> :
goto <bb 6>; [INV]
<bb 3> :
if (i_3 == 0.0)
goto <bb 5>; [INV]
else
goto <bb 4>; [INV]
<bb 4> :
<bb 5> :
# lastPoint_1 = PHI <i_3(3), 2.0e+0(4)>
i_10 = i_3 + 1.00000001490116119384765625e-1;
<bb 6> :
# lastPoint_2 = PHI <lastPoint_5(D)(2), lastPoint_1(5)>
# i_3 = PHI
<1.00000000000000002081668171172168513294309377670288085938e-2(2), i_10(5)>
if (i_3 <= 1.0e+0)
goto <bb 3>; [INV]
else
goto <bb 7>; [INV]
<bb 7> :
return lastPoint_2;
}
On the 6->3 edge we know that i_3 is [-INF, 1.0], so even adding a range-op
entry for the PLUS_EXPR, we'd know that i_3 is [-INF, 1.1], which is not enough
to fold the i_3 == 0.0 conditional. If you convert this testcase to integer
and turn off SCEV (and unrolling and FRE, etc), you'll notice that VRP doesn't
do much here (in either legacy nor ranger mode).
We would need SCEV to give us [1.0, 1.1] in order to fold the i_3 == 0.0
conditional. For that matter, if I hack SCEV to give us the expected end
points, I can get evrp to fold the conditional. I think once VRP is FP aware,
we can close this PR because this particular testcase is SCEV specific. So for
this particular testcase, perhaps we could open a SCEV+FP PR?
As an aside, the second conditional will not be folded by VRP (legacy or
ranger), even with SCEV, even if you convert the above testcase to
integer...it's either gotten later by unrolling+FRE for FP, or cddce for
integers.
What I'm trying to say is that even with FP VRP, which we'll have shortly, the
first conditional won't be folded because SCEV doesn't do floats, and the
second one won't be, because it's not VRP's job.
