This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining heuristics for C++
On Mon, Jul 09, 2001 at 11:06:31PM -0700, Mark Mitchell wrote:
>
>
> --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!
>
> 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.
>
> 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.
To do that, you need basically a backtracking framework - try inlining
compulsively for some amount of time and see if the resulting code size
of the inlined function is substantially smaller than the size of the
inlined function standalone. Except, of course, you really want likely
execution time rather than code size, but code size is a decent first
approximation :) Unless of course we enable some additional loop
unrolling.
This is something that would, as Dan said, be nice to have - some day,
when we have the framework to do it.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer