DIP56 Provide pragma to control function inlining

[Walter Bright]

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?