--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-25
16:56 ---
Yes, the regression is even worse on the closed-duplicate #18704. There you can
also find some analysis of inline parameter tuning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From giovannibajo at libero dot it 2005-02-25
16:43 ---
Why isn't this a critical regression? We're regressing *badly* on code
generation.
--
What|Removed |Added
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-25
10:06 ---
Patch at
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01571.html
improves the testcase from 16.2s to 12.1s (3.4: 5.0s) - aka, still not good
enough. As we have (with the patch) still size estimates for the
--- Additional Comments From kunert at physik dot tu-dresden dot de
2005-02-25 09:52 ---
Subject: Re: [4.0 Regression] threefold performance
loss, not inlining as much
Wow. Many thanks for that analysis. Now I will go and fetch the patch. Since
nobody seems to care about improving t
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-24
17:09 ---
With __attribute__((leafify)) sticked to v4c_quad and mult_pq runtime goes down
from 16.0s to 4.4s with recent gcc 4.0. For gcc 3.4.3 runtimes are 5.0s and
4.9s.
We indeed do not very well on estimating t
--- Additional Comments From kunert at physik dot tu-dresden dot de
2005-02-08 10:13 ---
Subject: Re: [4.0 Regression] threefold performance
loss, not inlining as much
Good idea.
However, this provides just another knob to tune the inlining and it is not
obvious where to apply that
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-02-03 17:32 ---
Subject: Re: [4.0 Regression] threefold performance
loss, not inlining as much
bonzini at gcc dot gnu dot org wrote:
> To the reporter: in this case you probably want __attribute__ ((
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-03
16:49 ---
To the reporter: in this case you probably want __attribute__ ((leafify)), just
in case, though you are right in expecting the compiler to inline it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28
01:04 ---
Final callgraph for amd64:
double accu1(const double*, const double*) [with int n = 2]/21: 22 insns (29
after inlining) needed inlinable asm_written
called by:
calls:
double f(const double*, const do
--- Additional Comments From hubicka at ucw dot cz 2004-12-24 21:09 ---
Subject: Re: [4.0 Regression] threefold performance loss, not inlining as much
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-24
> 20:36 ---
> Reduced testcase:
> const int LMAX =
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-24
20:36 ---
Reduced testcase:
const int LMAX = 4;
const int LMAX41 = 4*LMAX+1;
const int LMAX12 = (LMAX+1)*(LMAX+2)/2;
template
inline double accu1( const double* p1, const double* p2 )
{
double d = *p1 * *p2;
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06
05:20 ---
*** Bug 18704 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 15:48
---
Jan can you look into this testcase, this is one where we don't inline as much as 3.4
did.
(for ppc-darwin, it is much worse as templates have to go through a stub now so it is
much worse
there). Maybe t
13 matches
Mail list logo
