From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Fergus Henderson Cc: "gcc@gcc.gnu.org" Subject: Re: Inlining heuristics for C++ Date: Tue, 10 Jul 2001 00:13:00 -0000 Message-id: <87ith1l0i8.fsf@cgsoftware.com> References: <87r8vpo8rw.fsf@cgsoftware.com> <398850000.994745191@warlock.codesourcery.com> <20010710170030.A15073@hg.cs.mu.oz.au> X-SW-Source: 2001-07/msg00724.html Fergus Henderson writes: > On 09-Jul-2001, Mark Mitchell 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