This is the mail archive of the
mailing list for the GCC project.
Re: inline-limit: some experimental feedback
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: inline-limit: some experimental feedback
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Tue, 21 Aug 2001 19:58:30 -0400
- Cc: Bernd Schmidt <bernds at redhat dot com>,Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>,"Richard dot Kreckel at uni-mainz dot de" <Richard dot Kreckel at uni-mainz dot de>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- References: <firstname.lastname@example.org>
Mark Mitchell <email@example.com> writes:
> --On Tuesday, August 21, 2001 01:22:42 PM +0100 Bernd Schmidt
> <firstname.lastname@example.org> wrote:
>> On Tue, 21 Aug 2001, Gerald Pfeifer wrote:
>>> The proper fix really is to improve the inliner.
>> Is it possible to switch 3.0 back to the rtl inliner for C++?
> It's nontrivial (although not impossible), but it would be extremely
> risky -- and note that the new inliner does generate better code
> for lots of people in lots of cases.
> The inliner is getting blamed, but that is not the real problem.
> real problems with compile-times are coming from excessive memory use
> (partly due to inefficiencies in the tree nodes themselves, partly due
> to waste in the C++ front-end) and a slow garbage-collector. I've
> confirmed this with data on a variety of different programs.
> The slower run-times Gerald is reporting are not something I understand
> at this point.
Errr, they are due to not inlining iterators, because we hit the
I've verified this through profiling his applications.
What happens is we don't inline things where the call cost is less
than the cost to just inline, which happens quite often with
iterators, because we've already hit the various inlining limits.
This is the main missing heuristic.
Without it, you need to crank up the inline limit enough to get all
the functions where call cost exceeds inline cost to be inlined.
When you do that, you generate enough excess code to slow down
compilation by a large amount.
Past that missing heuristic, it's just random luck causing us to inline the right
functions, until we are doing it based on some kind of execution count
info, be it static or dynamic.
> Mark Mitchell email@example.com
> CodeSourcery, LLC http://www.codesourcery.com
"I stayed up all night playing poker with Tarot cards. I got a
full house and four people died.