inlining...

[Manu]

On 14 March 2014 22:02, John Colvin <john.loughran.colvin at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140314/700e5fa9/attachment.html>