DIP56 Provide pragma to control function inlining

[Steven Schveighoffer]

On Sun, 23 Feb 2014 21:05:32 -0500, 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.

But you are under-utilizing the message. There is the case that one wants  
inlining, even when -inline isn't passed to the compiler, for functions  
that would have been inlined if -inline was specified. That is your case,  
right?

But there is a case where the compiler for some reason has decided that  
inlining a function is not worth it, so even with -inline it doesn't do  
it. However, without the inlining, the function becomes horrendously slow.  
For example, functions that contain lazy parameters.

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

This is not a problem. The whole point is, if the compiler doesn't support  
the inlining, the code is useless. I WANT it to fail, there is no reason  
to version it out.

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

Huh? Then why even have the feature if the compiler is going to ignore  
your request!

This feature sounds completely useless to me, it certainly adds no real  
value that warrants adding a pragma. It may as well be called  
pragma(please_inline_pretty_pretty_please_ill_be_your_best_friend)

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

Compilers are not infallible. They may make mistakes, or not have enough  
information, which is the point of this feature. What is to say they don't  
make mistakes even with the correct amount of information?

And the reason I use a compiler rather than assembler is because I hate  
writing assembler :)

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

This is totally the wrong tack. First, I may have no idea how often a  
function will be used. Second, usage frequency has nothing to do with how  
inlining may affect the performance of an individual call. If an inlined  
function always executes faster than calling the function, I always want  
to inline.

For example, foo:

void foo(ref int x)
{
   ++x;
}

-Steve