https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 29 Mar 2017, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197 > > --- Comment #7 from Alexander Monakov <amonakov at gcc dot gnu.org> --- > No, with fixed-up inlining -ftracer sees reasonable edge probabilities. The > reason tracer makes things worse here, is that it clones the path leading to a > 50%/50% conditional branch (and correctly stops at that branch), making the > tiny BB under that branch ineligible(?) for if-conversion. We go from > > <BB0> > if (!cond) goto <BB2> > <BBcond> > var = VAL; // this can eventually become a cmov > <BB2> > > to > > <BB0_1> > if (!cond) goto <BB2> > goto <BBcond> > > ... > > <BB0_2> > if (!cond) goto <BB2> > <BBcond> > var = VAL; // this doesn't become a cmov > <BB2> > > > I think in principle if-conversion could still do its job here by duplicating > the conditional var=VAL assignment under BB0_1. > > Here's a silly compile-only sample where -O2 -ftracer is worse than -O2 due to > this effect: > > void f(long n, signed char *x) > { > for (; n; n--) { > long a=x[n], b; > if (!a) > a = 42; > b = x[a]; > if (b < 0) > b += a; > x[b] = 0; > } > } It's hard for tracer to predict followup optimization opportunities in the isolated path and weight that against missed if-conversion opportunities. Of course the fact that late phiopt runs after tracer / split-paths doesn't help, nor that phiopt doesn't catch this kind of if-conversion (the idea was that the RTL pass can do _much_ better in assessing if-conversion const/benefit). Tracer doesn't have a very sophisticated cost model either.
