[Mlir-commits] [mlir] [MLIR] Introduce support for early exits (PR #166688)
Mehdi Amini
llvmlistbot at llvm.org
Thu Feb 26 06:37:38 PST 2026
================
@@ -558,6 +571,89 @@ func.func @accelerator_compute(i64, i1) -> i64 { // An SSACFG region
}
```
+#### Region Terminator
----------------
joker-eph wrote:
> I think it can. We delegate SSACFG / graph region to an interface.
Of course we "can", but this is what I referred above as:
> 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.
To begin with, just the implementation of the verifier would have to change drastically if none of this was Core, and I'm not sure we could preserve the efficiency we have now with a "monolithic" design.
Most of the tooling around SSACFG regions would have to be thought differently.
(that said in the early days of MLIR, before open-sourcing, I was advocating for such a design, which got shut down because overly generic, too complex, and costly)
> Putting things into class OperationState comes at a cost: e.g., you have to account for it in the generic op syntax.
Sure, but that's no more "special treatment" than CFGs and everything else. Also a trait like "IsTerminator" does not impact the generic printer only because it is implicit with the position in the block, but that's not because we didn't intend any "special treatment": all of these are just as much "core" as any other.
For example, there is one thing we didn't make "core" and it is the RegionBranchOpInterface, we stopped at the region boundary and left the rest unspecified.
To some extent this PR may be the first time we'd start looking at cross-region control-flow in a way that affects the "core".
https://github.com/llvm/llvm-project/pull/166688
More information about the Mlir-commits
mailing list