On 14 March 2014 22:02, John Colvin <[email protected]> wrote: > > > Thanks for the explanations. > > Another use case is to aid propogation of compile-time information for > optimisation. > A function might look like a poor candidate for inlining for other > reasons, but if there's a statically known (to the caller) integer > parameter coming in that will be used to decide a loop length, inlining > allows that info to be propogated to the callee. Static loop lengths => > well optimised loops, with opportunities for optimal unrolling. Even with > quite a large function this can be a good choice to inline. >
Yup, this is a classic example. Extremely relevant. And it's precisely the sort of thing that an inline heuristic is likely to fail at. I don't know how good compilers are at taking this sort of thing into > account already. > I don't know if they try or not, but I can say from experience that results are generally unreliable. I would never depend on the inliner to get this right. On 14 March 2014 22:08, bearophile <[email protected]> wrote: > John Colvin: > > > ... >> > > If the function is private in a module, and it's called only from one > point (or otherwise the loop count is the same in different calls), I think > this optimization can be performed even if the function is not inlined. > This is probably true, but I would never rely on it. You have some carefully tuned code that works well, and then one day, some random unrelated thing tweaks a balance, and your previously good code is suddenly slow for unknown reasons. The point is, there are times when you know your code should be inlined; ie, it's not an 'optimisation', it's an expectation/requirement. A programmer needs to be able to express this.
