This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inline-limit: some experimental feedback
- To: Daniel Berlin <dan at cgsoftware dot com>
- Subject: Re: inline-limit: some experimental feedback
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Date: Wed, 22 Aug 2001 12:54:07 +0200 (CEST)
- cc: Mark Mitchell <mark at codesourcery dot com>, Bernd Schmidt <bernds at redhat dot com>, "Richard dot Kreckel at uni-mainz dot de" <Richard dot Kreckel at uni-mainz dot de>, <gcc at gcc dot gnu dot org>
On Tue, 21 Aug 2001, Daniel Berlin wrote:
> Errr, they are due to not inlining iterators, because we hit the
> inlining limit.
> 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.
Bad, but something like that had to be the cause, else I wouldn't
have suffered from such an incredible slow-down.
> This is the main missing heuristic.
Would this be hard to implement? Actually, didn't you have a patch
addressing this?
> 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.
Though, even if I set the limit to 10000, the generated code is still
measurably slower than for GCC 2.95.x.
Again, I'm willing to hand out our sources including a benchmark suite
who's interested to work on this, and I can also try patches and perform
such benchmarks by myself.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/