https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 29 Apr 2021, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 > > --- Comment #7 from Marc Glisse <glisse at gcc dot gnu.org> --- > Some key steps in the optimization: > PRE turns PHI<-1,0,1> > 0 into PHI<0,0,1> > reassoc then combines the operations (it didn't in gcc-10) > forwprop+phiopt cleans up (i>0)!=0?1:0 into just i>0. > > Having to wait until phiopt4 to get the simplified form is still very > long, and most likely causes missed optimizations in earlier passes. But > nice progress! Agreed - requiring PRE (and thus -O2) is also less than optimal for such a core feature. But the IL we get is simply awkward ;) ifcombine/phiopt2 see <bb 2> [local count: 1073741824]: if (i_1(D) == 0) goto <bb 5>; [50.00%] else goto <bb 3>; [50.00%] <bb 3> [local count: 536870913]: if (i_1(D) < 0) goto <bb 5>; [41.00%] else goto <bb 4>; [59.00%] <bb 4> [local count: 316753840]: <bb 5> [local count: 1073741824]: # c$_M_value_2 = PHI <0(2), -1(3), 1(4)> _4 = c$_M_value_2 > 0; I guess that's what we should try to work with. For PR99997 I have prototyped a forwprop patch to try constant folding stmts with all-constant PHIs, thus in this case c$_M_value_2 > 0, when there's only a single use of it (that basically does what PRE later does but earlier and for a very small subset of cases).
