From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-81199-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 29326 invoked by alias); 13 Aug 2003 22:59:06 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 29314 invoked from network); 13 Aug 2003 22:59:05 -0000
Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51)
  by sources.redhat.com with SMTP; 13 Aug 2003 22:59:05 -0000
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h7DMwifR001593
	for <gcc@gcc.gnu.org>; Wed, 13 Aug 2003 15:58:44 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T640870ceac118164e16f8@mailgate2.apple.com>;
 Wed, 13 Aug 2003 15:59:00 -0700
Received: from apple.com (mrs1.apple.com [17.201.24.248])
	by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h7DMwkWI022643;
	Wed, 13 Aug 2003 15:58:46 -0700 (PDT)
Date: Thu, 14 Aug 2003 00:21:00 -0000
Subject: Re: On inlining in C++ with unit-at-a-time code
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Jan Hubicka <hubicka@ucw.cz>, Joe Buck <jbuck@synopsys.com>,
   Gabriel Dos Reis <gdr@integrable-solutions.net>, gcc@gcc.gnu.org
To: Gerald Pfeifer <gerald@pfeifer.com>
From: Mike Stump <mrs@apple.com>
In-Reply-To: <Pine.BSF.4.56.0308140043110.12895@acrux.dbai.tuwien.ac.at>
Message-Id: <B697F64A-CDE1-11D7-A9D4-003065A77310@apple.com>
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-08/txt/msg00889.txt.bz2

On Wednesday, August 13, 2003, at 03:45 PM, Gerald Pfeifer wrote:
> On Thu, 7 Aug 2003, Jan Hubicka wrote:
>> Concerning the inlining limits, I believe we should increase them.
>
> Sure, your analysis seems convincing...

I wasn't going to chime in, but...

I'm happy with the above sort of testing/experiments and am happy to 
have them increased.  When we have a balance of complaints for and 
against a change, then we know it is time to fundamentally improve the 
algorithms involved.  It feels to me that we've erred on the too small 
side for a while.

Thanks for doing this work, and thanks to anyone that offers feedback 
on the `right' values to use, and how bad things are, if the defaults 
are right.