> On 10/09/13 10:11, Jakub Jelinek wrote: > > On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote: > >> This last point is crucial. I haven't looked at the code in question, > >> but one point to check is how the functions are called. If they are > >> often called with constant values, then they may be very much simplified > >> due to constant propagation. Secondly, if a function is inlined, the > >> compiler has full knowledge of the effects of the function "call" and > >> can thus optimise better (keeping data in registers over the "call", > >> shuffling around loads and stores, etc.). Finally, if the functions are > >> called in loops or other time-critical code, it can be worth spending > >> more code section space for a faster result (but sometimes smaller code > >> is faster due to caches, branch prediction buffers, etc.). > >> > >> The ideal situation is that LTO figures this out for you, and the code > > > > At least until LTO keeps to end up with unusable or hardly usable debug > > info, effectively requiring LTO for good compiler performance is a > > non-starter. And, the inliner we have is not dumb, if it sees an inline > > function, but it is too large, it will usually not inline it. > > So, rather than counting the lines of inline functions in headers, IMHO it > > is better to look at inliner's decisions about those functions, if it > > never inlines them, then supposedly moving them out of line is reasonable. > > > > Jakub > > > > That should be easy enough with "-Winline", I think.
What i also do from time to time is to do LTO profiledbootstrap and look into inline dump. Then you have inlining ordered by pretty realistic measure of benefits, so you see what matters and what not. Inliner knows that constant callbacks are good to inline and will bump up its limits. One problem is that we do have those functions as static inlines, so they ends up duplicated, with C++ we may consider moving them to comdat. Honza > > David
