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.
