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

[Matthias Springer]

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

Based on what we discussed I don't yet see the point for putting `num-breaking-region` into `OperationState`.

> > 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.

I buy that argument only if we say that in an ideal design, "region kind" and "isolated from above" should also get a field in `OperationState`.

> 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.

We already look up `RegionKindInterface` and `OpTrait::IsTerminator` for every region-based op in the verifier, so I wouldn't expect much of a slowdown. I also wouldn't think the implementation would change much: you still call a `getNumBreakingRegions(Operation *)` helper function, and it either returns `op->getNumBreakingRegions()` or queries the value from the interface.

> Most of the tooling around SSACFG regions would have to be thought differently.

What would have to change?

I'd like to make sure that we really want `num-breaking-region` in `OperationState`. Once it's there, it will be difficult to remove if we ever change our mind. (On the other hand, you can always start with an interface and then promote it into `OperationState` later. It would also be a smaller incremental change.)



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