DIP56 Provide pragma to control function inlining

Iain Buclaw ibuclaw at gdcproject.org
Sun Feb 23 23:04:11 PST 2014


On Feb 24, 2014 2:10 AM, "Walter Bright" <newshound2 at digitalmars.com> wrote:
>
> On 2/23/2014 5:45 PM, Brad Roberts wrote:
>>
>> At this point, you're starting to argue that the entire DIP isn't
relevant.  I
>> agree with the majority that if you're going to have the directive, then
it
>> needs to be enforcement, not suggestion.
>
>
> 1. It provides information to the compiler about runtime frequency that
it cannot obtain otherwise. This is very useful information for generating
better code.
>
> 2. Making it a hard requirement then means the user will have to put
versioning in it. It becomes inherently non-portable. There is no way to
predict what some other version of some other compiler on some other system
will do.
>
> 3. In the end, the compiler should make the decision. Inlining does not
always result in faster code, as I pointed out in another post.
>
> 4. I don't see that users really are asking for inlining or not. They are
asking for the fastest code. As such, providing hints about usage
frequencies are entirely appropriate. Micromanaging the method used is not
so appropriate. After all, the reason one uses a compiler in the first
place rather than assembler is to not micromanage the actual instructions.
>
>
> Perhaps the lesson is the word 'inline' carries certain expectations with
it, and the feature would be better positioned as something like:
>
>     pragma(usage, often);
>     pragma(usage, rare);

Also known as, hot and cold functions.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140224/3ac698df/attachment-0001.html>


More information about the Digitalmars-d mailing list