https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that we have
<bb 11> [local count: 966367640]:
__builtin_memcpy (_27, __l$_M_array_15, _17);
__result_28 = _27 + _17;
<bb 12> [local count: 1073741824]:
# __result_29 = PHI <_27(10), __result_28(11)>
...
if (_36 != 0B)
goto <bb 13>; [0.00%]
else
goto <bb 14>; [100.00%]
<bb 14> [local count: 1073741824]:
__guard ={v} {CLOBBER(eob)};
__guard ={v} {CLOBBER(eos)};
__l ={v} {CLOBBER(eos)};
_6 = vec1.D.25450._M_impl.D.24761._M_finish;
_4 = vec1.D.25450._M_impl.D.24761._M_start;
_9 = _6 - _4;
and while the value of _6 is __result_28 the AVAIL checking's code picks
_6 as leader since __result_28 wasn't deemed available when processing
the _6 def which is because of the limited mind of dominated_by_p_w_unex
which doesn't handle the unreachable edge into the middle BB 12 but only
unreachable outgoing edges from the top and unreachable incoming edges
into the bottom block.
In fact the top block handling looks to help only quite uncommon cases,
I'll try to rework it a bit.
