https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
It seems that until now, we didn't see an empty block feeding a PHI that
mattered:
<bb 2>
_3 = x_2(D) + 4294967292;
if (_3 <= 1)
goto <bb 5>; [41.00%]
else
goto <bb 3>; [59.00%]
<bb 5>
goto <bb 4>; [100.00%]
<bb 3>
_6 = x_2(D) + 4294967287;
_7 = _6 <= 1;
<bb 4>
# iftmp.3_4 = PHI <_7(3), 1(5)>
return iftmp.3_4;
we process back the first PHI operand with _7 == [1, 1]and eventually get to
x_2 = [9, 10].
the problem comes when we lok at the second phi argument. check_taken_edge
looks for a branch on the previous block which it can then evaluate the
operands with a LHS of [1,1]
with no branch, it assumes (no pun intended), that the previous block doesn't
provide any useful information because it has no LHS that it can propagate the
[1,1] into. and it simply stops.
I looked at checking if the block has only a single pred, to then check that
block to see if it has a branch.
This causes another issue. We then end up back at the if (_3 <= 1) branch
again, however we have already given _3 a value of [2, +INF] from the previous
path.. this new path wants to give it a value of [0,1], which would then
allow x_2 to be evaluated t0 [4,5] on that path.
the current mechanism intersect values when it calculates a new one. so
things again break down and are even uglier :-P
The assume pass currently has no concept of what values are of interest at the
end (ie the parameters), it just performs the "feeding def" walk back and
calculates a bunch of ranges, then when its done, the assume pass exports any
values it found that happen to be parameters.
Im thinking that perhaps we should instead throw away any existing values found
during the walk that are local to the function.. And if we calculate a value
for a parameter, we union it with any current value.
That will get this case correct (I believe), it just unclear to me yet if it
would affect anything else negatively. thoughts?
It also seems to me that if we encounter this situation, and the block feeding
the [1,1] constant phi argument has more than one predecessor, maybe we should
punt and assign no assume values.. its an IL where we aren't processing all
predecessor blocks which may lead to a TRUE result, so we aren't calculating
things properly..
Or if this solution works, maybe we simply process each predecessor the same
way.. again its unclear to me at this point, but we shall see.
