https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87608
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2018-10-15
Component|rtl-optimization |tree-optimization
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I believe this is another case where an early phiopt pass would help. We have
a sequence of
<bb 2> :
_1 = first_522(D) + 64;
t_525 = *first_522(D);
_3 = MEM[(int *)first_522(D) + 64B];
if (_3 <= t_525)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
<bb 3> :
<bb 4> :
# iftmp.0_391 = PHI <_3(3), t_525(2)>
in which the VRP1 pass mixes up the CFG via jump-threading so that the
later phiopt pass no longer sees this min/max patterns.
I have (even posted) a nearly finished patch to move phiopt1 early but
it had some fallout. I'm not sure if I can find enough cycles to finish
it for GCC 9. Some ideas were restricting it to min/max/abs recognition
because that's what most PRs talk about. Another idea would be to move
both ifcombine and phiopt before the first real jump-threading pass (vrp1)
since most "bad" effects of moving phiopt were related to missed ifcombine
optimizations.
