[Mlir-commits] [mlir] [MLIR] Introduce support for early exits (PR #166688)

Mehdi Amini llvmlistbot at llvm.org
Thu Feb 26 06:05:08 PST 2026


================
@@ -558,6 +571,89 @@ func.func @accelerator_compute(i64, i1) -> i64 { // An SSACFG region
 }
 ```
 
+#### Region Terminator
----------------
joker-eph wrote:

> Having a small OperationState (and LangRef) is a nice property because it keeps the "core" of the language small. So generally speaking, I would opt for interfaces/traits unless there's a good reason why it cannot be done that way or limits usability.

I see it differently : LangRef provides the basic blocks of MLIR, the general rules that applies everywhere.
We don't have a "JSON" like representation where all the semantics is delegated to interfaces (we could have done it this way maybe), but we have foundations that try to be consistent: the baseline being mostly about control-flow, domination / post-domination rules, etc. 
Since we're actually touching the control flow, which is under LangRef purview, it can't just be delegated to interfaces.

> There is currently no special treatment for terminators. I.e., there is no bool isTerminator; in OperationState. We have OpTrait::IsTerminator instead. (But terminators are mentioned in the LangRef.)

We don't need it in OperationState because this is a static property of an operation.

> There is currently no special treatment for region terminators. 

Kind of the same as above, we have it in operation state by the fact of not having another block successor and being the last operation in the block.

> There is currently no special treatment for SSACFG/graph regions. We have RegionKindInterface interface instead. (Mentioned in the LangRef.)

What do you mean by "special treatment"? This is all implemented in the core of the verifier, which is as "special treatment" as it gets I think. Also all the CFG / dominance rules are implement in the core of the framework, not in an interface / plugin implementation.



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


More information about the Mlir-commits mailing list