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

[Kirill Chibisov]

kchibisov wrote:

>The emitc.load op models the side effect of reading the value.

Maybe the variable should have `hasSideEffect` field indicating whether it can actually has side effect, e.g. `volatile` qualified, since I don't think you can have any of the side effects listed on the page you've linked with regular `emitc.lvalue<i32>` as of now.

>If this would be used inside an expression we wouldn't be able to ensure the correct semantics (i.e. ordering of multiple load ops), as the [order of evaluation](https://en.cppreference.com/w/c/language/eval_order) is unspecified in C.

I don't think you'd be able to ensure it either unless you restrict it even further. From the generated code point of view, the code is _exactly the same_ since all you add is _intermediate steps_. The end expressions are exactly the same, just the variable is named differently because you'd have a temporary binding. So, I'm not quite sure what the current restriction _prevents_ in _generated_ code.

If the point is to ensure that during the _mlir_ passes it won't end up in expression and transformations could be performed on _defined_ order than maybe the _load_ could be _inlined_ like `emitc.expression` (using inline attribute) during the emitter phase?

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