DIP56 Provide pragma to control function inlining

[Andrei Alexandrescu]

On 2/23/14, 4:33 PM, Walter Bright wrote:
> On 2/23/2014 3:55 PM, Mike wrote:
>> The difference is it was explicitly told do do something and didn't.
>> That's
>> insubordination.
>
> I view this as more in the manner of providing the equivalent of runtime
> profiling information to the optimizer, in indirectly saying how often a
> function is executed.
>
> Optimizing is a rather complicated process, and particular optimizations
> very often have weird and unpredictable interactions with other
> optimizations.
>
> For example, in the olden days, C compilers had a 'register' storage
> class. Optimizers' register allocation strategy was so primitive it
> needed help. Over time, however, it became apparent that uses of
> 'register' became bit-rotted due to maintenance, resulting in all the
> wrong variables being enregistered. Compiler register allocation got a
> lot better, almost always being better than the users'. Not only that,
> but with generic code, and optimization rewrites of code, many variables
> would disappear and new ones would take their place. Different CPUs
> needed different register allocation strategies. What to do with
> 'register' then?
>
> The result was compilers began to take the 'register' as a hint, and
> eventually moved to totally ignoring 'register', as it turned out to be
> a pessimization.
>
> I suspect that elevating one particular optimization hint to being an
> absolute command may not turn out well. Inlining already has performance
> issues, as it may increase the size of an inner loop beyond what will
> fit in the cache, for just one unexpected result. For another it may
> mess up the register allocation of the caller. "Inlining makes it
> faster" is not always true. Do you really want to weld this in as an
> absolute requirement in the language?

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.


Andrei