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.

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

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

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