================
@@ -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 {
----------------
bcardosolopes wrote:
> This differs from the loops, where the condition has its own block. I find
> myself curious why that is.
Like Andy said, `if` is significantly more simple. Worth mentioning that we
redesigned loops 3 or 4 times already, and more will likely come once
loop-based CIR transformations get explored.
> Also, what happens with variable declarations in the condition? Do we
> properly set scope for those?
It's in the scope. My long term plan here has been to tag the scopes (e.g.
`cir.scope if`), and all the other variations we see in CIR's LexicalScope
right now), should help clarify some of the source code connections and passes
might have an easier time when searching for specific parents.
> What do you think?
IMO adding one more region and an operation to yield only creates more
complications for analysis: operations that were previously dominating are now
in a region sibling with then/else - something that could have been a dominator
check now will envolve looking at other regions, for no clear benefit I can see
at the moment, do you have anything in mind? My experience so far with using
regions is that C/C++ often backstabs some nice design attemps, so I'm more on
the skeptical side. If you feel encourage to try this approach, I recommend
experimenting in the incubator to double check IR soundness with our CIR test
coverage.
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
