public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: Mark Mitchell <mark@codesourcery.com>
Cc: Joe Buck <jbuck@synopsys.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: C++ compile-time regressions
Date: Thu, 02 Aug 2001 00:20:00 -0000	[thread overview]
Message-ID: <Pine.BSF.4.33.0108011301040.3036-100000@taygeta.dbai.tuwien.ac.at> (raw)
In-Reply-To: <Pine.BSF.4.33.0107251701360.21080-100000@taygeta.dbai.tuwien.ac.at>

[ 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.

Gerald

2001-08-01  Gerald Pfeifer  <pfeifer@dbai.tuwien.ac.at>

	* params.def (PARAM_MAX_INLINE_INSNS): Change default to 600.
	Correct comment that had been missed in the previous change.

Index: params.def
===================================================================
RCS file: /cvs/gcc/egcs/gcc/params.def,v
retrieving revision 1.3.2.5
diff -u -3 -p -r1.3.2.5 params.def
--- params.def	2001/07/26 13:55:02	1.3.2.5
+++ 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.  */
 DEFPARAM (PARAM_MAX_INLINE_INSNS,
 	  "max-inline-insns",
 	  "The maximum number of instructions in a function that is eligible for inlining",
-	  100)
+	  600)

 /* The maximum number of instructions to consider when looking for an
    instruction to fill a delay slot.  If more than this arbitrary




  reply	other threads:[~2001-08-02  0:20 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18 18:41 GCC 3.0.1 Status Report Mark Mitchell
2001-07-19  6:17 ` Joseph S. Myers
2001-07-20  3:45 ` Nathan Sidwell
2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer
2001-07-20 10:54   ` Nathan Sidwell
2001-07-20 16:41     ` Loren James Rittle
2001-07-23  5:17       ` Gerald Pfeifer
2001-07-23 11:56       ` Daniel Berlin
2001-07-23  2:51     ` Gerald Pfeifer
2001-07-20 10:55   ` Mark Mitchell
2001-07-20 14:22     ` Joe Buck
2001-07-20 16:28       ` Mark Mitchell
2001-07-20 21:05         ` Joe Buck
2001-07-23 10:44           ` Gerald Pfeifer
2001-07-23 11:12             ` Joe Buck
2001-07-23 11:57               ` Gerald Pfeifer
2001-07-23 13:30                 ` Joe Buck
2001-07-24  7:18                   ` Gerald Pfeifer
2001-07-24  7:55                     ` Daniel Berlin
2001-07-24 10:09                     ` Joe Buck
2001-07-24 10:19                       ` Gabriel Dos Reis
2001-07-24 10:44                         ` Joe Buck
2001-07-24 10:56                           ` Gabriel Dos Reis
2001-07-24 10:25                       ` Daniel Berlin
2001-07-24 10:49                         ` Joe Buck
2001-07-24 11:08                           ` Daniel Berlin
2001-07-23 14:36                 ` Mark Mitchell
2001-07-25  8:06                   ` Gerald Pfeifer
2001-08-02  0:20                     ` Gerald Pfeifer [this message]
2001-08-02  0:26                       ` C++ compile-time regressions Mark Mitchell
2001-08-02 11:00                       ` aoliva
2001-08-02 12:00                         ` Mark Mitchell
2001-08-02 12:26                           ` aoliva
2001-08-02 12:37                             ` Joe Buck
2001-08-02 12:41                             ` Mark Mitchell
2001-08-02 12:48                               ` Joe Buck
2001-08-02 13:53                       ` Daniel Berlin
2001-08-07  7:54                         ` Gerald Pfeifer
2001-07-23 11:54             ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Daniel Berlin
2001-07-23 12:42               ` Bernd Schmidt
2001-07-23 12:50               ` law
2001-07-23 13:15                 ` Daniel Berlin
2001-07-23 14:00                   ` law
2001-07-20 10:57   ` Daniel Berlin
2001-07-20 14:20   ` Joe Buck
2001-07-25 17:52 ` GCC 3.0.1 Status Report Marc Espie
2001-08-13 23:15   ` Mark Mitchell
2001-08-03  6:53 C++ compile-time regressions Richard Kenner
2001-08-03 10:20 ` Daniel Berlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.BSF.4.33.0108011301040.3036-100000@taygeta.dbai.tuwien.ac.at \
    --to=pfeifer@dbai.tuwien.ac.at \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=jbuck@synopsys.com \
    --cc=mark@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).