On 14 March 2014 22:02, John Colvin <john.loughran.colvin@gmail.com> 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 <bearophileHUGS@lycos.com> 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.