https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> There is a missed optimization at the gimple level for sure.
>
>
> if (d_11 > 1)
> goto <bb 5>; [59.00%]
> else
> goto <bb 4>; [41.00%]
>
> <bb 4> [local count: 391808389]:
>
> <bb 5> [local count: 955630225]:
> # iftmp.1_6 = PHI <0(3), 2(4)>
> c = iftmp.1_6;
>
> The store to c is removed by the time we get to fixup_cfg3 but the phi is
> around still:
>
> In .mergephi2:
> d_11 = (short unsigned int) a.4_5;
> if (d_11 > 1)
> goto <bb 5>; [59.00%]
> else
> goto <bb 4>; [41.00%]
>
> <bb 4> [local count: 391808389]:
>
> <bb 5> [local count: 955630225]:
> # iftmp.1_6 = PHI <0(3), 2(4)>
> _10 = a.4_5 & 65535;
> if (_10 == 0)
> goto <bb 6>; [50.00%]
> else
> goto <bb 8>; [50.00%]
>
>
> Then thread1 decides to thread based on the if statement for some unknown
> reason ....
> even if the first if statement was dead as the phi is dead. Maybe we need a
> quick DCE sometime right after forwprop2?
>
> But maybe jump threading should NOT happen here.
The thread in the thread1 pass is 3->5->6->7. It is an attempt to fold d_11 !=
0 at the end of BB6:
<bb 3> [local count: 955630225]:
d_11 = (short unsigned int) a.4_5;
if (d_11 > 1)
goto <bb 5>; [59.00%]
else
goto <bb 4>; [41.00%]
<bb 4> [local count: 391808389]:
<bb 5> [local count: 955630225]:
# iftmp.1_6 = PHI <0(3), 2(4)>
_10 = a.4_5 & 65535;
if (_10 == 0)
goto <bb 6>; [50.00%]
else
goto <bb 8>; [50.00%]
<bb 6> [local count: 477815112]:
if (d_11 != 0)
goto <bb 7>; [33.00%]
else
goto <bb 8>; [67.00%]
<bb 7> [local count: 157678986]:
foo ();
The only way it can fold d_11 != 0, is by chasing back to the 3->5 edge. The
PHI in BB5 is irrelevant, as the conditional in it is a check against _10 not
the iftmp.1_6 PHI result. What is useful is the 3->5 edge.
I don't understand why you think this thread is incorrect.
