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

Matthias Gehre llvmlistbot at llvm.org
Thu Aug 22 02:37:05 PDT 2024


mgehre-amd wrote:

> > Maybe the `emitc.load` could be allowed inside the `emitc.expression`, since it doesn't do anything _useful_ on its own and more of a type-system level safety? Then `form-expressions` pass will likely deal with it correctly.
> 
> The `emitc.load` op models the side effect of reading the value. 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.
> 
> But I'd like to hear opinions from @aniragil or @mgehre-amd.

Wouldn't all possible orders of emitc.load inside an expression still give the same result, as long as there is no emitc.store inside the expression? As our emitc.load is close to a lvalue-to-rvalue conversion, and those  are mostly created implicitly in C++ code, it seems fine to me to allow emitc.load in expressions.

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


More information about the Mlir-commits mailing list