inlining...

[Nick Sabalausky]

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