[Mlir-commits] [mlir] [MLIR] Introduce support for early exits (PR #166688)
Mehdi Amini
llvmlistbot at llvm.org
Mon Mar 2 05:32:54 PST 2026
================
@@ -558,6 +571,89 @@ func.func @accelerator_compute(i64, i1) -> i64 { // An SSACFG region
}
```
+#### Region Terminator
----------------
joker-eph wrote:
We're back to:
1) That's kind of OK for boolean queries, and even then you need to think about the "maybe" case. You don't have boolean anymore, you have the "mightHaveXXX" queries which are really "no", or "maybe". Technically we have a tri-state and could return `std::optional<bool>` for `mlir::isMemoryEffectFree(op)`.
2) For non-boolean queries, this is much more annoying (the `collectAllNestedMaybePredecessors` for example), the client gets a list of operations that "may" correspond to the request. This requires to always think about the "I don't know case" -> this is added complexity (code complexity, testing coverage, etc. but more importantly "mental model" complexity) on **all** the client code path for these APIs.
3) Performance: interface lookup is really not fast :( ; you don't want to encode this on the most common APIs (`class Operation` as much as possible). All the tricks in the implementation of `class Operation` were implemented there since the beginning to avoid this. I don't subscribe to the "let's implement something slow before re-engineering it all when we figure we have a terribly slow system" actually (I've been there on some past project, it's a never ending quest later).
https://github.com/llvm/llvm-project/pull/166688
More information about the Mlir-commits
mailing list