https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109486
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Known to fail| |13.0
CC| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2023-04-12
Component|rtl-optimization |tree-optimization
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed also on x86_64. We end up with
<bb 2> [local count: 118111600]:
_10 = this_6(D)->ptr_;
_11 = this_6(D)->data_;
if (_10 > _11)
goto <bb 3>; [89.00%]
else
goto <bb 4>; [11.00%]
<bb 3> [local count: 955630225]:
# _12 = PHI <_1(3), _10(2)>
_1 = _12 + 18446744073709551608;
this_6(D)->ptr_ = _1;
if (_1 > _11)
goto <bb 3>; [89.00%]
else
goto <bb 4>; [11.00%]
<bb 4> [local count: 118111600]:
return;
where for some reason we fail to sink the store out of the loop. Ah,
at sink/sm time we still have
<bb 3> [local count: 955630225]:
# _12 = PHI <_1(6), _10(5)>
_1 = _12 + 18446744073709551608;
this_6(D)->ptr_ = _1;
MEM[(long int *)_12 + -8B] ={v} {CLOBBER};
if (_1 > _11)
there's another bug about this inability to handle CLOBBERs (from LIM),
but I can't find it right now. I think we need to get rid of
pointer-based clobbers way earlier (before loop opts - currently they
survive until fab), but the issue is also present for decl clobbers.
