https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
Furthermore, this PR is also a good example of a case where we want to inject
updated values into the Ranger's iterator.
<bb 2> :
goto <bb 6>; [INV]
<bb 3> :
ui_8 = ~xe_3;
if (ui_8 == 0)
goto <bb 4>; [INV]
else
goto <bb 5>; [INV]
<bb 4> :
ui_10 = xe_3 >> gg_9(D);
<bb 5> :
# ui_4 = PHI <ui_8(3), ui_10(4)>
_1 = ui_4 == 0;
_2 = (int) _1;
xe_11 = xe_3 % _2;
<bb 6> :
# xe_3 = PHI <0(2), xe_11(5)>
if (xe_3 <= 0)
goto <bb 3>; [INV]
else
goto <bb 7>; [INV]
The initial evaluation of
# xe_3 = PHI <0(2), xe_11(5)>
causes The backedge 5->6 to evaluate xe_11, which is dependant on the value of
xe_3 (its a cycle). This requires evaluating values thru the cycle and Ranger
calculates that the edge 6->3 causes xe_3 = [-INF, 0]
which feeds into
ui_8 = ~xe_3;
resulting in a range of [0, +INF] for ui_8
A bunch of other things are figured out, and ultimately it decides that xe_3
evaluates to [0,0]. Very cool, this is good.
lots of things fall out from this, and when we get to folding
ui_8 = ~xe_3 and xe_3 is now known to be [0,0]
we can fold it into
ui_8 = -1
THe problem is during the initial backedge calculations, we decided ui_8 was
initially [-1, +INF], and without the iterative injection to indicate we have
a new value for ui_8, the ranger continues to use the cached value of [-1,
+INF]. Even though we know it is the constant -1 now.
So we're doing better than before because we didn't get any of those values,
but it looks funny in the listing:
63 range_of_stmt (ui_8) at stmt ui_8 = -1;
TRUE : (63) range_of_stmt (ui_8) int [-1, +INF]
duh.
I originally planned to add the new value injection early in the next stage 1.
It will recognize that the previously calculated value of ui_8 is stale when
the thing it is dependent on (xe_3) has a value different than the one which
was used to calculate it.
When this is done, we will basically be able to fold most of this function away
in EVRP.
The basic mechanism is already in place, its just a matter of figuring out how
to efficiently decide when to trigger the re-evaluation. There may yet be
something we can do about this in this stage 1.
