================
@@ -462,6 +462,58 @@ def ReturnOp : CIR_Op<"return", [ParentOneOf<["FuncOp",
"ScopeOp", "DoWhileOp",
let hasVerifier = 1;
}
+//===----------------------------------------------------------------------===//
+// IfOp
+//===----------------------------------------------------------------------===//
+
+def IfOp : CIR_Op<"if",
+ [DeclareOpInterfaceMethods<RegionBranchOpInterface>,
+ RecursivelySpeculatable, AutomaticAllocationScope, NoRegionArguments]>{
+
+ let summary = "the if-then-else operation";
+ let description = [{
+ The `cir.if` operation represents an if-then-else construct for
+ conditionally executing two regions of code. The operand is a `cir.bool`
+ type.
+
+ Examples:
+
+ ```mlir
+ cir.if %b {
----------------
andykaylor wrote:
> do you have anything in mind?
I don't have anything specific in mind. I just have a general preference for
consistency. If I've written some code to handle `cir.if` and it knows how to
find the condition and any associated initialization, then I want to extend
this code to handle `cir.while`, it would surprise me to have to find the
condition and initialization differently. Of course, without actually going
through that process it's hard to say which way is more natural in practice.
> If you feel encourage to try this approach, I recommend experimenting in the
> incubator to double check IR soundness with our CIR test coverage.
I am OK with having this PR proceed with the current representation and
revisiting the issue in the incubator if we decide to explore a change. At
least until we have enough of the implementation upstreamed to believe that
people might be using it, I would agree that's a good general approach.
https://github.com/llvm/llvm-project/pull/134333
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
