This is the mail archive of the gcc@gcc.gnu.org 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]
Other format: [Raw text]

Re: GCC inline parameters (PR 10160 testcase)


On Fri, 2003-05-02 at 15:22, Steven Bosscher wrote:
> Op za 03-05-2003, om 00:09 schreef Mark Mitchell:
> > On Fri, 2003-05-02 at 15:01, Steven Bosscher wrote:
> > > Op vr 02-05-2003, om 23:36 schreef Mark Mitchell:
> > > > On Fri, 2003-05-02 at 14:14, Eric Botcazou wrote:
> > > > > > I believe that we are about to ship 3.3 with a set of inline parameter
> > > > > > defaults that are way too agressive.  These can cause huge increases
> > > > > > in compilation time and memory over that with a more conservative
> > > > > > set of parameters.
> > > > > 
> > > > > I think it's even worse: the new heuristics of the tree inliner is simply
> > > > > broken, period. See http://gcc.gnu.org/ml/gcc/2003-04/msg00871.html for my
> > > > > own take on PR 10160.
> > > > 
> > > > Hmm; I didn't know we'd changed our inlining heuristics to have this
> > > > MIN_INLINE_INSNS concept.
> > > > 
> > > > You can, however, set that to zero using --params.
> > > > 
> > > > But, I think the scheduler is your real problem here; there shouldn't be
> > > > n^2 algorithms in there, unless they have clamps.
> > > 
> > > No, that inliner heuristic is just wrong.  See PR 10155 for example.
> > 
> > Why do you say that?
> 
> Because I analyzed the report and you only read the final post in the
> audit trail?

Naw, I read it.  It just didn't seem to get me to the same place as you.

BTW, I didn't add the inlining heuristic whereby small functions are
always inlined.

> Look at the problem description:
> 
> options     |   gcc -c -O2   |  gcc -c -O3
> ------------------------------------------
> gcc 3.2.2   |        19 Mb   |       16 Mb
> gcc 3.3     |       113 Mb   |      120 Mb
> gcc 3.4     |       120 Mb   |     1772 Mb
> 
> Guess what?  This joke on memory abuse goes away with "-O3
> -fno-unit-at-a-time".

First, -funit-at-a-time is not in 3.3, so this is a bit off-topic
relative to Eric's comment.

Second, Jan's analysis just points out that something is wrong with the
inlining strategy, not the particular heuristic to which you point.

Third, if -O3 enables -funit-at-a-time, then whoever did that has
introduced a regression, and should fix the problem -- perhaps by taking
-funit-at-a-time out of -O3.

Yours,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC


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