Potential inliner simplification?

[Daniel Murphy]

"Nick Sabalausky"  wrote in message news:lh5qon$1f7l$1 at 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.