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