[Bug rtl-optimization/80197] pgo dramatically pessimizes scimark2 MonteCarlo benchmark

[rguenther at suse dot de]

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.