Here is the current state of the prototype to discuss on one of the alternatives proposed above: EmitC lvalue. (I haven’t put to much thought into the changes in the emitter or validation of the ops. I just added code where ever needed to make most of the tests pass.)
To summarize the changes. Ops return results or take operands with lvalue type where appropriate. Explicit lvalue-to-rvalue ops are used in places where lvalue types are not expected in the IR. During emission these ops don’t produce any output. Instead the mapping from SSA values to variable names explicitly checks if the defining op is an LValueToRValueOp and then recursively looks up the variable name of it’s operand.
A few things to consider:
- If a conversion replaces a value with an op producing a lvalue type.
LValueToRValueOpsneed to be inserted for every use of the result value. I think a source materialization can be used for this, but I haven’t tested this yet. An example for this upstream would be in theSCFToEmitCPasswherescf.ifresults are replaced byemitc.variableops which get assigned to in both regions of the correspondingemitc.ifop. - Many ops in the dialect should maybe be restricted to not take and produce lvalues (arithmetic operators for example).
For visibility: @marbre @aniragil @mgehre-amd