On 3/14/2014 8:37 AM, Manu wrote:
On 14 March 2014 22:02, John Colvin <john.loughran.col...@gmail.com> 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.
