DIP56 Provide pragma to control function inlining

[Vladimir Panteleev]

On Monday, 24 February 2014 at 04:14:08 UTC, Andrei Alexandrescu 
wrote:
> I'll add an anecdote - in HHVM we owe a lot of speedups to the 
> careful use of "never inline" and "always inline" gcc pragmas 
> IN ADDITION TO the usual "inline" directives. We have factual 
> proof that gcc makes the wrong inline decisions BOTH WAYS if 
> left to decide.
>
> If we define pragmas for inlining, "always inline" must mean 
> always inline no questions asked and "never inline" must mean 
> always prevent inlining no questions asked. Anything else would 
> be a frustrating waste of time.

I think there is another, distinct use case for an inline pragma 
where "try to inline" is useful - namely, turning on the 
equivalent of the compiler "-inline" switch for just one 
function. I believe this is the original rationale behind the DIP 
(enabling inlining for certain functions even in debug builds, 
because otherwise the debug builds become so slow as to be 
unusable). In this case, whether the compiler actually succeeds 
at inlining the function doesn't matter as long as it does the 
same thing as for an optimized (-inline) build.

Thus, I think there should be "try to inline" (same as -inline) 
and "always inline" (failure stops compilation).