This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining heuristics for C++
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Inlining heuristics for C++
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Tue, 10 Jul 2001 03:20:44 -0400
- Cc: Daniel Berlin <dan at cgsoftware dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- References: <398850000.994745191@warlock.codesourcery.com>
Mark Mitchell <mark@codesourcery.com> writes:
> --On Monday, July 09, 2001 09:46:59 PM -0400 Daniel Berlin
> <dan@cgsoftware.com> wrote:
>
>> Right now, they are horrific.
>
> Hey, thanks a lot. :-) They are, actually, the same ones we had in
> the RTL inliner, just about -- except that we can inline so much more!
>
It's not your fault, it's because someone set flag_default_inline to
1, so all methods are inline.
and since DECL_INLINE, < 10k insns and actually possible to inline were the
inliner's criteria, we ended up with a lot of 10k insn
functions, even when the original function was say, one stmt that was
a call. :)
We effectively did a breadth first search of the call tree for a function, inlining
everything possible until we hit 10k insns for that function.
The only case where we didn't hit 10k insns is if we *couldn't find
that many functions to inline* :).
> I think your ideas are reasonable. Nathan Sidwell has been thinking
> about these issues, too; you should coordinate with him to try to
> get some decent ideas and some decent measurements.
:)
I really also don't think we will exacerbate the memory problems. The
memory problems are from every method being inline, and every inline
up to 10k insns being done.
So we generate a *lot* of copies.
And we *were* deferring just about everything anyway, since they were
all marked inline.
So compared to 3.0 we can reduce memory usage just by calming the
inliner.
And still be deferring everything. And inlining where we won't
increase code growth. And reduce compile time by a factor of of 4.
Neat, eh?
Our problem was so big, that we look like geniuses for fixing it.
I think we should "lose" the mail archives, and pretend we spent
months fixing it.
:)
>
> One long-term challenge is that we would like to inline when somehow
> that allows major simplifications. For example, if there is a giant
> function involving tons of calcuation, but we know that the argument
> is `3', and that means we can fold all the calculations, then we
> should do the inlining, even if the inlined function is nominally
> giant. I have no idea how to do this, though. It's probably not worth
> bothering about.
>
> --
> Mark Mitchell mark@codesourcery.com
> CodeSourcery, LLC http://www.codesourcery.com
--
"I went to the cinema, and the prices were: Adults $5.00,
children $2.50. So I said, "Give me two boys and a girl."
"-Steven Wright