[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