www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Auto-inlining

reply Nigel Sandever <nigelsandever btconnect.com> writes:
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.
Sep 12 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Sep 13 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Sep 13 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"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

 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

 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

 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).
Sep 13 2004