[Mlir-commits] [mlir] [mlir][EmitC] Model lvalues as a type in EmitC (PR #91475)

[Kirill Chibisov]

kchibisov wrote:

>In general, we could use the comma operator to enforce evaluation order within expressions. While I don't think we can define variables inside comma expressions, specifically when --declare-variables-at-top is used we could fold dangerous loads in-order using commas, e.g.

I don't think that it's worth it given that it's overly complicated and doesn't solve much, you still define the variables in the end of the day where the goal is not to, if you write them on the same line with comas it won't change much.

There're two solutions I could think of, based on what I've seen so far:

Track side effects inside the emitter, since everything is already in place there and the cache is there. The load operation could check whether it has side effect or not and could be inlined if there's no side effect or user asked to inline anyway potentially resulting in _undefined_ evaluation in the generated code. 

Or:

Define a trait `HasLoadSideEffect`, which could be used to unsure that load's operand inside the `CExpression` is not having this trait.


As a side note, I think _mine_ use case is quite different to what you're going for with lvalue, since we want something _more readable_ being generated in the end and looking like something a _regular person could write_, doing explicit bindings for subscript is certainly not that (I'd use `at` or something that does bounds checking). Though, having more _defined_ things generated is a _good default_ from what I can say.

https://github.com/llvm/llvm-project/pull/91475