"Nick Sabalausky" wrote in message news:[email protected]...
- "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.
