[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression

["hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From hubicka at ucw dot cz  2004-12-07 17:50 -------
Subject: Re:  [4.0 Regression] Inlining limits cause 340% performance regression

> 
> ------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-12-07 15:35 -------
> Subject: Re:  [4.0 Regression] Inlining limits
>  cause 340% performance regression
> 
> On Tue, 7 Dec 2004, Richard Guenther wrote:
> 
> > static inline void foo() {}
> > void bar() { foo(); }
> >
> > which for -O2 -fprofile-generate produces
> >
> > bar:
> >         addl    $1, .LPBX1
> >         pushl   %ebp
> >         movl    %esp, %ebp
> >         adcl    $0, .LPBX1+4
> >         addl    $1, .LPBX1+16
> >         popl    %ebp
> >         adcl    $0, .LPBX1+20
> >         addl    $1, .LPBX1+8
> >         adcl    $0, .LPBX1+12
> >         ret
> 
> Mainline manages to produce
> 
> bar:
>         addl    $1, .LPBX1
>         pushl   %ebp
>         movl    %esp, %ebp
>         adcl    $0, .LPBX1+4
>         popl    %ebp
>         ret
> 
> but that's RTL instrumentation?

It is instrumentation after inlining.  Before inlining you have two
functions so you get two entry points.
Doing little inlinng before profiling would do the trick here, but it
needs some restructuring first.

Honza
> 
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.


-- 


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