inlining...

[ponce]

On Thursday, 20 March 2014 at 08:35:22 UTC, Ola Fosheim Grøstad 
wrote:
> Nothing prevents you to introduce exceptions as an extension 
> though. I want inline(0.5) as default, but also be able to 
> write inline(1) for inline always and inline(0) for inline 
> never.
>
> func1(){} // implies inline(0.5) weighting
> inline func2(){} // same as inline(1) weighting, inline always
> inline(0.75) fun31(){} // increase the heuristics weighting
> inline(0) func4(){} // never-ever inline
>

It looks promising when seen like that, but introducing explicit 
inlining/deinlining to me correspond to a precise process:

1. Bottleneck is identified.
2. "we could {inline|deinline} this call at this particular place 
and see what happens"
3. Apply inline directive for this call. Only "always" or "never" 
is ever wanted for me, and for 1 level only.
4. Measure and validate like all optimizations.

Now after this, even if the inlining become harmful for other 
reasons, I want this inlining to be maintained, whatever the 
cost, not subject to random rules I don't know of. When you tweak 
inlining, you are supposed to know what you are doing, and it's 
not just an optimization, it's an essential tool that enables 
other optimizations, help disambiguate aliasing, help the 
auto-vectorizer, help constant propagation...

In the large majority of cases it can be left to the compiler, 
and in the 1% cases that matters I want to do it explicitely full 
stop.