[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:

> By the way you refer to OperationState but to be more precise we should refer to Operation right?

Yes, I meant `class Operation`.

(But adding fields there also means having to update other classes/APIs such as `struct OperationState`, `OpBuilder::create`, `Operation::create`, `OperationEquivalence`, `OperationFingerPrint`, generic op syntax + printer + parser, bytecode reader + writer, `DynamicOpDefinition`, ODS code generator.)

> Now the complication with this will come from supporting unregistered ops.

Feels quite MLIR-ish: `mightHaveTerminator`, `mightHaveEffect`, `mightHaveTrait`, `mightNotProgress`...

Can we conclude that from a functionality point of view, interface/trait vs. `class Operation` makes a difference only for unregistered ops?

Do we have concrete examples of patterns / transformations / analyses that would have to bail out (or pessimize) in an interface/trait-based approach (as opposed to `class Operation` approach) wrt. unregistered ops? These could be objective criteria in favor of the `class Operation`.

Everything else that we discussed so far is highly subjective to me. (E.g., optimizing for performance, when it's unclear if performance will actually be a problem in practice.)


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