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).
