3.0.1 performance

[Kurt Garloff]

Hi Daniel,

On Fri, Aug 17, 2001 at 02:47:13PM -0400, Daniel Berlin wrote:
> Kurt Garloff <kurt@garloff.de> 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).

Regards,
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7gMByxmLh6hyYd04RAmz3AJ4+X3T7g0yqhAOK0KxTKMi2YIzKyACgw4Ua
6woJC5O+w9IYOPMEqSTepvw=
=IMrn
-----END PGP SIGNATURE-----