Re: Inlining heuristics for C++

[Daniel Berlin <dan at cgsoftware dot com>]

Fergus Henderson <fjh@cs.mu.oz.au> writes:

> On 09-Jul-2001, Mark Mitchell <mark@codesourcery.com> wrote:
>> 
>> 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.
> 
> Another, similar case when you really want to inline are when the body
> of the function contains a call to a virtual method (or other indirect
> function call) and the type of the object and hence its vtable
> (or the value of the function pointer) is known in the caller.
> That's handy because you can then inline the virtual method
> (or indirect function call), which may lead to further opportunities
> for simplification.

Real Devirtualization can be done with region based frameworks, or
interprocedural analysis.
No need for inlining all virtuals.

> 
> For some applications this can really pay off significantly,
> so it is worth doing in the long run, although right now
> it's probably more important on just fixing the most egregariously
> bad heuristics rather than trying 
> 
> We do some of this kind of stuff in the Mercury compiler.  For example,
> we specialize function calls where one of the parameters is a known
> higher-order term (a.k.a. closure; think of it as a known function
> pointer).  

Yup, this is procedure cloning (or so all the papers and books i have
call it, besides closure).  It's part of most aggressive inliner
frameworks, but you really need either to defer everything again.
> We also do "deforestation" optimization, which is
> related to this idea of specializing calls where the caller has
> information about a decision (e.g. a switch) in the callee.
> There's a paper [1] on our web page which describes those and
> some of the other optimizations that we do.
COol.


-- 
"Are there any questions?
"-Steven Wright