DIP56 Provide pragma to control function inlining

Dmitry Olshansky dmitry.olsh at gmail.com
Mon Feb 24 00:01:35 PST 2014


24-Feb-2014 03:49, Walter Bright пишет:
> On 2/23/2014 3:00 PM, Dmitry Olshansky wrote:
>> You actually going against yourself with this argument - for porting you
>> typically suggest:
>>
>> version(OS1)
>>   ...
>> else version(OS2)
>>   ...
>> else
>> static assert(0);
>
> There's not much choice about that. I also suggest moving such code into
> separate modules.
>
>
>> Your nice tired and true way of doing things is EQUALLY FRAGILE (if
>> not more)
>> and highly coupled to the compiler but only SILENTLY so.
>
> That's very true. Do you suggest the compiler emit a list of what
> optimizations it did or did not do? What makes inlining special, as
> opposed to, say, enregistering particular variables?
>

GCC has these attributes (including flatten to fully unroll all calls in 
a function) for a good reason. Let's face the fact that compilers 
nowhere near perfect with decisions about inlining. Especially so when 
building libraries.

Inlining is special in the sense that compiler doesn't know (there is 
not a single hint today in D) if any particular function should be a 
part of object code (following the ABI and referenced elsewhere) or just 
a logical piece of code that is reused (using any convenient calling 
convention or inlined).

Let me turn the question sideways - what if no_inline will be a hint to 
compiler and it may feel free to inline the function anyway? Will you be 
happy with such a pragma? It's that simple - you either gain control, or 
stay with wishy-washy hopes.

As you said in contrast with register allocation (that is ridiculously 
hard problem) later with time it turned out that trying to pin outsmart 
the compiler is something people were not good at in general.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list