inlining...

[Chris Williams]

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

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.