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

Gil Rapaport llvmlistbot at llvm.org
Wed May 15 13:08:17 PDT 2024


================
@@ -698,6 +703,47 @@ LogicalResult emitc::LiteralOp::verify() {
     return emitOpError() << "value must not be empty";
   return success();
 }
+
+//===----------------------------------------------------------------------===//
+// LValueToRValueOp
+//===----------------------------------------------------------------------===//
+
+LogicalResult emitc::LValueToRValueOp::verify() {
+  Type operandType = getOperand().getType();
+  Type resultType = getResult().getType();
+  if (!llvm::isa<emitc::LValueType>(operandType))
+    return emitOpError("operand must be a lvalue");
+  if (llvm::cast<emitc::LValueType>(operandType).getValue() != resultType)
+    return emitOpError("types must match");
+
+  Value result = getResult();
+  if (!result.hasOneUse()) {
----------------
aniragil wrote:

I agree with @mgehre-amd (stated similar thoughts [here](https://discourse.llvm.org/t/rfc-separate-variables-from-ssa-values-in-emitc/75224/2) and [here](https://discourse.llvm.org/t/rfc-separate-variables-from-ssa-values-in-emitc/75224/7)). EmitC uses C variables to model MLIR SSA values, that hasn't changed. We only want to separate the C variables used for modeling SSA registers from those used for modeling memory locations (BTW, We can/should emit SSA C variables as `const`). Emitting a copy to a fresh variable at lvalue-to-rvalue's location sounds like the correct implementation of lvalue-to-rvalue semantics, including any side effect needed to copy the lvalue's state at that point. Delaying lvalue-to-rvalue's side effects until the use is only valid if the lvalue hasn't been modified in that interval.

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


More information about the Mlir-commits mailing list