www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Potential inliner simplification?

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
This is something that's been in the back of my mind lately.

First, some background:
------------------------

DMD's inliner makes a very strong distinction between inlining a 
function call as a statement (when no return value is used) vs inlining 
it as an expression (when there is a return value used). The functions 
for inlining the nodes inside function bodies are basically implemented 
twice - once for "as statement" and again for "as expression".

ATM, this duplication appears to be necessary because:

- "Inline as Statement" CANNOT be performed whenever a return value is 
used, since statements don't have return values (only expressions do).

- "Inline as Expression" CANNOT inline functions which use certain types 
of statements, such as (non-unrolled) for loops, because these 
statements are not expressible as expressions.

So this duplication maximizes the chances a function call is inlinable.

My reasoning:
--------------

However, all those restrictions (and consequently, the need for separate 
"as expression" vs "as statement" codepaths) are forced by one reason: 
DMD's AST doesn't support expressions that contain statements.

That seems natural since the D language itself doesn't allow statements 
to be used as expressions. However, that doesn't mean the AST can't 
*internally* support them.

Proposal:
----------

If DMD added a new subclass of Expression, say "StatementExp" 
(essentially a reverse counterpart of "ExpStatement"), then, at least in 
theory, all the "Inline as Statement" vs "Inline as Expression" could be 
merged into one unified set:

Any statement that D cannot normally support as an expression could be 
converted to an expression by placing it inside a StatementExp. Thus, 
the entire "inline as a statement" portion of the inliner could be 
eliminated since the "as an expression" branch alone would be powerful 
enough to handle all cases.

My questions:
--------------

A. Is this reasoning even valid in the first place?

B. Are there enough untapped future enhancements remaining in the 
inliner for this to actually be worthwhile at all?

C. How much trouble would adding a "StatementExp" cause for the various 
backends? I don't know anything about how the backend(s) handle DMD's 
AST or what would even be involved in supporting a new node type.
Mar 28 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 3/29/2014 2:55 AM, Nick Sabalausky wrote:

 This is something that's been in the back of my mind lately.

 First, some background:
 ------------------------

 DMD's inliner...


I want to emphasize that I'm not actually trying to push for this right 
now. For starters, I just wanted to see whether it was reasonably sound, 
and if so, whether it would actually be worthwhile.
Mar 29 2014
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Nick Sabalausky"  wrote in message news:lh5qon$1f7l$1 digitalmars.com...


 - "Inline as Statement" CANNOT be performed whenever a return value is 
 used, since statements don't have return values (only expressions do).


Technically it _could_ be used, it would just have to splice the returned 
variable into the calling expression.


 Any statement that D cannot normally support as an expression could be 
 converted to an expression by placing it inside a StatementExp. Thus, the 
 entire "inline as a statement" portion of the inliner could be eliminated 
 since the "as an expression" branch alone would be powerful enough to 
 handle all cases.


We could...


 A. Is this reasoning even valid in the first place?


Yep.


 B. Are there enough untapped future enhancements remaining in the inliner 
 for this to actually be worthwhile at all?


Only in the short term IMO.


 C. How much trouble would adding a "StatementExp" cause for the various 
 backends? I don't know anything about how the backend(s) handle DMD's AST 
 or what would even be involved in supporting a new node type.


IIRC the other backends don't use the frontend's inliner, because they have 
powerful backend inliners available.  So the only glue layer affected would 
be DMD's, and I think that would also be the hardest to update thanks to the 
way expressions are lowered to elem trees (ie no flow control is possible in 
the IR either, ?: becomes OPcond and , becomes OPcom)

Another issue is we'd then have a fairly major expression type that only 
appeared in -inline builds.  I expect that would result in a _lot_ of bugs.

I suspect the effort would be better spent doing inlining in the backend, 
where better low-level information about the function complexity is 
available and the constructs are lower-level and more manageable.
Mar 29 2014
prev sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
The last frontend inliner improvement [1] remains stalled for 6+ 
months on what looks like a backend bug.

Another PR [2] seems to be stalled on the issue, it has been 
stalled for 1+ year.

I personally wouldn't much effort into this until the cause is 
found.

[1] https://github.com/D-Programming-Language/dmd/pull/2561
[2] https://github.com/D-Programming-Language/dmd/pull/1426
Mar 30 2014