https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81958
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
We see
<bb 4> [count: 0]:
# eq_7 = PHI <eq_14(D)(2), eq_16(8)>
# ivtmp.7_23 = PHI <0(2), ivtmp.7_24(8)>
_25 = (unsigned int) ivtmp.7_23;
if (maxidx_15(D) > _25)
goto <bb 3>; [0.00%]
else
goto <bb 5>; [0.00%] // loop exit
<bb 5> [count: 0]:
if (maxidx_15(D) == _25)
goto <bb 6>; [0.00%]
else
goto <bb 10>; [0.00%]
<bb 7> [count: 0]:
# eq_9 = PHI <eq_7(10), eq_18(6), eq_16(9)>
printk (eq_9); [tail call]
return;
and the appearant uninit use is on the 10->7 edge, when maxidx != _25
but at the same time maxidx > _25. We don't realize that the
maxidx == _25 condition is always true. The possible easiest way
is probably to rewrite the in-loop condition to maxid != _25 somewhere
(ivcanon?).
uninit analysis itself just sees maxid <= _25 && maxid ==_25 as the
initialized cases - it could possibly analyze how _25 evolves
when defined in a loop to further optimize this to true.
