https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108139
--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Andrew Pinski from comment #2)
> Folding statement: if (a.3_5 != 0)
> Folding predicate a.3_5 != 0 to 1
> Folded into: if (1 != 0)
>
> I don't see how that could be possible. There is some issue coming from the
> (not used on this path) uninitialized variable c too.
<bb 5> [local count: 59055799]:
a.3_5 = a;
b.2_4 = b;
<bb 6> [local count: 114863530]:
# c_2 = PHI <c_9(D)(5), a.3_5(9)>
<bb 7> [local count: 1073741824]:
if (a.3_5 != 0)
goto <bb 4>; [94.50%]
else
goto <bb 8>; [5.50%]
The problem is that c_9 is an undefined value in the PHI.. with only 2
arguments, we try to be clever (and this is important in other places), and
say, ok, we'll assume it has the same value as the other argument and we create
an equivalence between c_2 and the other argument, a.3_5
The only way to get to the 6->9 edge is to have processed the if statement
already, and therefore we'd know that a.3_5 is ~[0, 0], sowe determine that c_2
is also ~[0,0].
When we visit the if statement, we know a.3_5 is varying, but we also look at
what equivalences a.3_5 has, and voila c_2 is equivlant o a.3_5, so we refine
the value to match c_2 and then decide we can fold away the if as always true.
we don't seem to run into this at hihger optimization levels because bb6 and
bb7 are merged, and with the PHI in the same block,we don't trigger the
outgoing edge equivalence evaluations :-P so we pick up the original VARYING
result for a.3_5 and don't adjust it with its "equivalence c_2".
hum.
