• Nigel Sandever (21/21) Sep 12 2004 If possible, could someone in the know give me an indication of what cri...
• Andy Friesen (8/23) Sep 13 2004 A cursory scan of inline.c (of the DMD source) suggests that short
• Arcane Jill (17/20) Sep 13 2004 Really? So, like
• Ben Hinkle (15/34) Sep 13 2004 too

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.

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

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








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:



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

"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








 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:



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