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.
