This is the mail archive of the
mailing list for the GCC project.
Re: inline-limit: some experimental feedback
Jack Lloyd <firstname.lastname@example.org> writes:
> On Tue, 21 Aug 2001, Richard B. Kreckel wrote:
>> > However, tweaking this parameter is a band-aid in any case: Even if we
>> > tune for maximum compile-time performance or maximum run-time performance,
>> > the result with GCC 3.0 and 3.0.1 is *still* worse than GCC 2.95.x in both
>> > terms (for my projects at least).
>> Just for the record: for my projects this is not the case.
>> GCC 3.0 produces faster code.
> Also just for the record, so does my project. Very much faster.
Maybe I should put up a web page with a detailed analysis of the
problem, so people stop analyzing and coming up with the same analysis
The reason the RTL inliner works so much better in a lot of cases is
1. It's heuristic is better.
This is easily fixable, and gives a lot better code if you use the RTL
inliner heuristic in the tree inliner.
2. It's unintentionally more selective.
The limitations of the RTL inliner only really affect code that is
rarely speed critical anyway (I.E. varargs functions). Since the tree
inliner has no such restrictions, we end up inlining the wrong things,
since we have no profile guided inlining.
I"m working on this on the ast-optimizer-branch (i'll be back to
working on it soon, anyway), and even with static heuristics, we do a
*lot* better inlining (The main thing you actually need is to be able
to guess loop iterations).
We could also benefit from procedure cloning.
The other solution to the problem is to use either interprocedural analysis, or
region based compiling.
"I have a microwave fireplace in my house... The other night I
laid down in front of the fire for the evening in two minutes.