This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 3.0.1 performance

Hi Daniel,

On Fri, Aug 17, 2001 at 02:47:13PM -0400, Daniel Berlin wrote:
> Kurt Garloff <> writes:
> > On Fri, Aug 17, 2001 at 08:54:24AM -0400, Phil Edwards wrote:
> >
> > So the docu seems outdate. Anyway, I'd vote for upping the default based on
> > the results posted. 1000 seems like a compromise. I'd personally vote for
> > more (say 2500), as the value used to be much higher before (10k or 15k) and
> > we do not want to risk too drastic changes between 3.0.0 and 3.0.1,
> > do we?
> Errr, yes, we want drastically better compile time.
> The main reason 600 isn't good enough for some applications is that
> our heuristics still aren't good.  Even using the one from integrate.c
> does better. I have a patch that uses the one from integrate.c that should only
> need 600 insns of inlining, but get alot better performance, at very small
> compile time increase.

You mean like lots of code which gets eliminated later during constant
propagation, but accounted for in the inline heuristics, e.g.?
I guess that happens especially often in templated C++ code and that's why
it hit me so bad.
Given that, I would not go for 600. I'm just thinking of horrible results
users will report (and SPEC base might give, peak should be OK, as people
will hopefully find the -finline-limit switch). A performance drop of a
factor 2.5 for going from 3.0 to 3.0.1 is really not so nice.
I'd really up this number by a factor of two. Maybe for C++ only?

Another question is why we don't have two limits: One for code that the
programmer requested to inline by the inline keyword (or by in class decl
implementation) and one that the compiler found itself (-finline-functions
resp. -O3).

Kurt Garloff                   <>         [Eindhoven, NL]
Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
Linux: SCSI, Security          <>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]