On Friday, 14 March 2014 at 22:12:38 UTC, Nick Sabalausky wrote:
On 3/14/2014 8:37 AM, Manu wrote:
On 14 March 2014 22:02, John Colvin
<[email protected]> wrote:
I don't know how good compilers are at taking this sort of
thing into
account already.
I don't know if they try or not, but I can say from experience
that results
are generally unreliable.
I would never depend on the inliner to get this right.
I don't know how this compares to other inliners, but FWIW,
DMD's inliner is pretty simple (By coincidence, I was just
digging into it the other day):
Every expression node (ie non-statement, non-declaration) in
the function's AST adds 1 to the cost of inlining (so ex: 1+2*3
would have a cost of 2 - one mult, plus one addition). If the
total cost is under 250, the function is inlined.
Also, any type of AST node that isn't explicitly handled in
inline.c will prevent a function from ever being inlined (since
the ijnliner doesn't know how to inline it). I assume this is
probably after lowerings are done, though, so more advanced
constructs probably don't need to be explicitly handled.
There is one other minor difficulty worth noting: When DMD
wants to inline a function call, and the function's return
value is actually used (ex: "auto x = foo();" or "1 + foo()"),
the function must get inlined as an expression. Unfortunately,
AIUI, a lot of D's statements can't be implemented inside an
expression ATM (such as loops), so these would currently
prevent such a function call from being inlined.
I don't know how easy or difficult that would be to fix.
Conceptually it should be simple: Create an Expression type
StatementExp to wrap a Statement as an expression. But other
parts of the backend would probably need to know about it, and
I'm unfamiliar with the rest of the backend, so have no idea
what that would/wouldn't entail.
Not that it can't be done (AFAIK), but since the subject came
up I thought I'd give a brief overview of the current DMD
inliner, just FWIW.
Probably one easy adjustment that would result in a lot of gain
in optimization would be to bump the lower bound of 250 if the
function is an operator overload.
