Redesign around compile/decode time local variables that map to SSA definitions?

[ghost]

Could introducing compile-time/decode-time local variables lead to a more efficient AST?

Let them be named a clocal. Operators would accept arguments in these and write their results to these, so there would be no expressions. There would still be the current local variables, but these would need explicit operators get_local and get_local to access them, or perhaps they could share an index space with the clocal variables. The current block structure would be retained, but there would be no expressions which would resolve a number of issues at hand, such as discarding expression values.

Way out of my depth, but so long as all uses of these clocal variables were dominated by they definition would they map to SSA definitions? Could a single-pass decoder and SSA transform optimize all their references away, and a lot more easily than if general local variables were used? The runtime decoder would just have to check that uses are dominated by their definitions, and it would be a validation error if not.

This might help on patterns that make multiple uses of a definition, This pattern does not currently fit the expression pattern but would still appear to map to SSA definitions. Currently local variables appear to be needed for such patterns, and from what I understand the single pass decoder does not optimize their use and transform them to SSA definitions?

Discarding unused expression results is causing some difficulties in the post-order decoder. Avoiding expressions entirely avoids this.

When working with a bundle of values, such as in multiple value expressions, the expression pattern becomes rather limited. With the call_multiple proposal in #280 the results of calls would be written directly to local variables but these are not optimized away in the single SSA pass and code generators will need to do more work in later passes to optimize away uses of these local variables. Might a concept such as the clocal variables help here, where the call_multiple operator could write to the clocal variables which would map to SSA definitions rather than local variables?

[ghost]

Looking at an actual decoder SSA transform it's clear that it does optimize local variable accesses well, that there appears to be no difference between an implicit expression temp versus breaking the expression down to single operations reading a writing to local variables. So the main point of this issue seems a just a misunderstanding, sorry for the noise.

I still wonder if the decoder SSA transform could benefit from a declaration on some local variables that might allow them to be accounted for more efficiently, so that they could be handled as efficiently as the expression temps. The v8 code does not appear to record these expression temps in the SSA environment, and with a suitable declaration I wonder if some variables could also be handled more efficiently? Further if it were possible to handle these temps more efficiently in the decoder if being less dependent on expressions might be more practical.