This is the mail archive of the
mailing list for the GCC project.
Re: GCC inline parameters (PR 10160 testcase)
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
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". And the only thing that unit-at-a-time does right
now is making inline decisions based on a call graph. And for this
particular test case _everything_ is inlined! But since there is no
limit on how big a function can grow with inlining, memory blows up and
> The end of that PR points at a quadratic algorithm elsewhere in the
In PR 10155, there is a _huge_ increase in memory. The quadratic
algorithm Zdenek talks about in the audit trail is completely
unrelated. It was a reaction on my remark that there was a compile time
increase from 25s with "-O2" to 30s with "-O2 -funswitch-loops". But
the that is unrelated to the actual problem that should be discussed in
this PR. It is just a bit unfortunate from that POV that those posts
ended up in the audit trail.
Let me quote from Honza's reply to my analisis, which is one post above
the one you refer to:
> The increase in memory at -O3 is a result of unit at a
> time compilation (which is why I CC you, Honza). You
> can check that by compiling with -O2 + all flags enabled
> at -O3 except -funit-at-a-time:
> > ./cc1 10155.c -quiet -ftime-report -O2
> TOTAL : 24.74 0.74 26.24
> > ./cc1 10155.c -quiet -ftime-report -O2 -funswitch-loops
> -frename-registers -finline-functions
> TOTAL : 31.49 0.59 33.87
> > Loop unswitching is responsible for most of the compile
Zdenek, this really ought not to happen, what is going on?
> time increase.
> Now add -funit-at-a-time, and kabooooom! you lose.
> > Apparently unit-at-a-time should still honor some size
> constraints, and it does not in its current form.
It should be more problem of inlining heuristics, than unit-at-a-time
(ie unit-at-a-time enables more inlining oppurtunities but it is
inlining heuristic mistake to take so many of them).
Or perhaps we manage to flatten functions called once into one
extraordinarily large function body and give up on it. I will try to
investigate it, but my current priority is to get unit-at-a-time working
on C++. Fixing this testcase should be easy then :)