If possible, could someone in the know give me an indication of what criteria the D compiler uses to decide whether to inline a sub or method?

Currently, my interest is with the Win32 implementation, but if there are any generalisations that can be made about this with regard to how other compiler back-ends might implement this, that would also be of interest.

Note. I'm not asking for exact specifications here, just general indicators of what might cause (or prevent) a sub from being inlined.

The reason for the question is the fairly common situation in portable applications of having small pieces of code, one or two lines or even a partial statement, that is used widely in the code (but wouldn't normally be enough to factor into a subroutine; or is performance critical), but needs to be slightly different on different platforms.

This is often done in C using conditionally compiled macros. An alternative is to make the code a subroutine and mark it as inline. The latter can allow many such pieces (of often otherwise unrelated) code to be maintained in platform dependant files/directories away from the main line platform independanty code whilst still allowing the compiler to perform block-level optimisations across the calling code.

So, having a feel for how the compiler decides when to inline a function, could influence how best to deal with specific cases.

Thanks. njs.

Nigel Sandever wrote:
> If possible, could someone in the know give me an indication of what criteria the D compiler uses to decide whether to inline a sub or method?
> 
> Currently, my interest is with the Win32 implementation, but if there are any generalisations that can be made about this with regard to how other compiler back-ends might implement this, that would also be of interest.
> 
> Note. I'm not asking for exact specifications here, just general indicators of what might cause (or prevent) a sub from being inlined.
> 
> The reason for the question is the fairly common situation in portable applications of having small pieces of code, one or two lines or even a partial statement, that is used widely in the code (but wouldn't normally be enough to factor into a subroutine; or is performance critical), but needs to be slightly different on different platforms. 

A cursory scan of inline.c (of the DMD source) suggests that short functions which are static, final, or non-class-method are most likely to be inlined.  Nested functions (?!), vararg functions, and functions which recieve 'inout' or 'out' arguments are not inlined.

One of the greatest things about DMD is that the source code can be understood by mere mortals. :)

 -- andy

In article <ci49ap$1ap3$1@digitaldaemon.com>, Andy Friesen says...

>Nested functions ... are not inlined.

Really? So, like

#    int f1(int x) { return x; }
#    int f2(int x) { return f1(x); }
#    int f3(int x) { return f2(x); }
#    int f4(int x) { return f3(x); }
#    int f5(int x) { return f4(x); }
#    int f6(int x) { return f5(x); }

Seems to me that the expression f6(x) should be inlined to just x. Is that too complicated? If so, can we have the "inline" keyword as compensation?


>functions which recieve 'inout' or 'out' arguments are not inlined.

So:

#    void f(inout int x) { ++x; }

doesn't get inlined? Again, if the compiler is going to make the wrong choices here, shouldn't we programmers be able to make the decision instead?

I am in principle in favor of having the compiler make the decision - but only if it's going to make the /right/ decision.

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ci4bhn$1bur$1@digitaldaemon.com...
> In article <ci49ap$1ap3$1@digitaldaemon.com>, Andy Friesen says...
>
> >Nested functions ... are not inlined.
>
> Really? So, like
>
> #    int f1(int x) { return x; }
> #    int f2(int x) { return f1(x); }
> #    int f3(int x) { return f2(x); }
> #    int f4(int x) { return f3(x); }
> #    int f5(int x) { return f4(x); }
> #    int f6(int x) { return f5(x); }
>
> Seems to me that the expression f6(x) should be inlined to just x. Is that
too
> complicated? If so, can we have the "inline" keyword as compensation?

nested functions means things like
int f6(int x) {
  int f5(int x) {return x;}
  return f5(x);
}

> >functions
> >which recieve 'inout' or 'out' arguments are not inlined.
>
> So:
>
> #    void f(inout int x) { ++x; }
>
> doesn't get inlined? Again, if the compiler is going to make the wrong
choices
> here, shouldn't we programmers be able to make the decision instead?
>
> I am in principle in favor of having the compiler make the decision - but
only
> if it's going to make the /right/ decision.

Same was said for the "register" keyword for variables way back when. The current compiler state can change any time to inline more stuff but the focus has been on bugs so I wouldn't expect the inlining to improve much for a while. Changing the language to compensate would be a mistake, though (IMO).