This is the mail archive of the
mailing list for the GCC project.
Re: C++ compile-time regressions
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: C++ compile-time regressions
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Date: Thu, 2 Aug 2001 09:19:42 +0200 (CEST)
- cc: Joe Buck <jbuck at synopsys dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
[ Includes patch. Okay for branch and mainline? ]
On Wed, 25 Jul 2001, Gerald Pfeifer wrote:
> Yes, I've been working on this now. To be honest, I don't have time to
> do this, but I'll try to have something in time for 3.0.1 -- somehow.
So, here we go. (The first column is the value of PARAM_MAX_INLINE_INSNS.)
-O2 -O3 -O2 -O3
100 8:29 8:48 4000228 3990276
500 8:24 8:53 4136996 4126148
600 8:33 8:59 4158820 4156068
700 8:52 9:32 4169028 4222436
800 8:34? 10:27 4179652 4315396
1000 9:09 11:27 4239076 4425860
1500 9:49 14:05 4336260 4637060
2000 10:47 23:47 4435428 4758052
To me, 600 seems like a definite and affordable improvement here; I'd
be a bit hesitant to go over 700.
>> Realistically, I think we have to be willing to compromise here; the 3.0.1
>> compiler is going to be slower *and* probably generate slower code than
>> 2.95, which is too bad, but that seems to be where we're at. If we could
>> get to 10-25% on both figures that would be better than having one figure
>> small and the other massive.
> The problem is, on both ends of the scale (that is, either slower code
> or slower generation) the *better* value is already around 25%, so a
> compromise will be worse than that for *both* values.
While I still see what I wrote as quoted above as a problem, here is the
patch I had promised.
I cannot perform regression testing anytime soon, so if this is required,
someone else has to do that and install the patch for me. I'll also try to
run detailed performance tests, but it's clear from previous results that
we will recover at least a bit.
2001-08-01 Gerald Pfeifer <firstname.lastname@example.org>
* params.def (PARAM_MAX_INLINE_INSNS): Change default to 600.
Correct comment that had been missed in the previous change.
RCS file: /cvs/gcc/egcs/gcc/params.def,v
retrieving revision 220.127.116.11
diff -u -3 -p -r18.104.22.168 params.def
--- params.def 2001/07/26 13:55:02 22.214.171.124
+++ params.def 2001/08/02 05:45:02
@@ -39,12 +39,12 @@ Boston, MA 02111-1307, USA.
function. Increasing values mean more agressive inlining.
This affects currently only functions explicitly marked as
inline (or methods defined within the class definition for C++).
- The default value of 10000 is arbitrary but high to match the
- previously unlimited gcc capabilities. */
+ The original default value of 10000 was arbitrary and caused
+ significant compile-time performance regressions. */
"The maximum number of instructions in a function that is eligible for inlining",
/* The maximum number of instructions to consider when looking for an
instruction to fill a delay slot. If more than this arbitrary