[Bug lto/57290] [4.9 Regression] After r198333 the aermod runtime is ~10% slower when compiled with -fprotect-parens and -flto

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290

--- Comment #1 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 15 May 2013, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
> 
>             Bug ID: 57290
>            Summary: [4.9 Regression] After r198333 the aermod runtime is
>                     ~10% slower when compiled with -fprotect-parens and
>                     -flto
>            Product: gcc
>            Version: 4.9.0
>             Status: UNCONFIRMED
>           Severity: normal
>           Priority: P3
>          Component: lto
>           Assignee: unassigned at gcc dot gnu.org
>           Reporter: dominiq at lps dot ens.fr
>                 CC: rguenth at gcc dot gnu.org
> 
> After r198333, the aermod runtime is more than 10% slower when compiled with
> -fprotect-parens and -flto:
> 
> (1) -Ofast -funroll-loops
> (2) -fprotect-parens -Ofast -funroll-loops
> (3) -Ofast -funroll-loops -fwhole-program -flto
> (4) -fprotect-parens -Ofast -funroll-loops -fwhole-program
> (5) -fprotect-parens -Ofast -funroll-loops -fwhole-program -flto
> 
> revision:   198332  198333
> 
> (1)          18.11   17.74
> (2)          17.70   17.61
> (3)          17.66   18.34
> (4)          18.47   18.49
> (5)          17.80   20.70

There is a lot of noise in these numbers(?) the patch, apart from

+       * passes.c (init_optimization_passes): Schedule a copy-propagation
+       pass before complete unrolling of inner loops.

should have had no effect on performance (well, in theory, that is).
Can you check whether reverting the above part changes the results?

Also, what's the variance of the numbers?  Are (1) to (4) effectively
the same performance r198332 vs. r198333?  (make sure to disable
address-space randomization for benchmarking)