https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that we call do_rpo_vn without having SSA form updated and thus
we see
<bb 5> [local count: 90350471]:
# c.4_22 = PHI <0(4), _40(24)>
_8 = a[c.4_22];
_9 = _8 ^ 1;
a[c.4_22] = _9;
_10 = c.4_22 + 1;
<bb 6> [local count: 11166912]:
_16 = 3;
_12 = b.6_23 + 1;
<bb 22> [local count: 11166912]:
# b.6_33 = PHI <_12(20)>
<bb 23> [local count: 90350471]:
# c.4_35 = PHI <c.4_22(22)>
_37 = a[c.4_35];
_38 = _37 ^ 1;
a[c.4_35] = _38;
_40 = c.4_35 + 1;
if (_40 <= 2)
goto <bb 24>; [89.00%]
else
goto <bb 25>; [11.00%]
but I think the PHI use in bb 23 will be _10 after updating SSA. Though
need_ssa_update_p is false - tree_unroll_loop will call update SSA.
Ah, after unroll but before fuse we have
<bb 5> [local count: 90350471]:
# c.4_22 = PHI <_10(10), 0(4)>
and
<bb 23> [local count: 90350471]:
# c.4_35 = PHI <0(22), _40(24)>
we've changed how CFG copying may alter PHI args. fuse_loops does
/* The PHI nodes of the second body (single-argument now)
need adjustments to use the right values: either directly
the value of the corresponding PHI in the first copy or
the one leaving the first body which unrolling did for us.
See also unroll_jam_possible_p() for further possibilities. */
gphi_iterator psi_first, psi_second;
e = single_pred_edge (next->header);
for (psi_first = gsi_start_phis (loop->header),
psi_second = gsi_start_phis (next->header);
!gsi_end_p (psi_first);
gsi_next (&psi_first), gsi_next (&psi_second))
{
that we can iterate PHI args in lock-step this way is not guaranteed.
