https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122493
--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #10)
> >+FAIL: gcc.dg/pr81165.c scan-tree-dump-not optimized " [/%] "
>
> I fixed this by not removing forwarding blocks with phis until loops are
> there. loops creation will cause the recreation of them but that can go
> wrong. Anyways loop finding is done early (ethread which is the 3rd pass,
> only ccp and forwprop are before).
I was wrong about totally wrong about this. current_loops is true here.
I don't see why or where ccp is splitting this:
```
<bb 5> :
# t0_27 = PHI <t0_36(3), t0_27(4), t0_33(2)>
# t1_28 = PHI <t1_37(3), t1_28(4), t1_34(2)>
# i_29 = PHI <i_35(3), i_40(4), i_35(2)>
```
into:
```
<bb 5> :
# t0_41 = PHI <-1(3), 0(2)>
# t1_42 = PHI <t1_37(3), 2(2)>
# i_43 = PHI <0(3), 0(2)>
<bb 6> :
# t0_27 = PHI <t0_41(5), t0_27(4)>
# t1_28 = PHI <t1_42(5), t1_28(4)>
# i_29 = PHI <i_43(5), i_40(4)>
```
So this looks like it comes from cleanup_tree_cfg_noloop then we undo it.
Specifically this:
/* If we have more than one entry to the loop header
create a forwarder. */
So let's try not remove that ....