[Mlir-commits] [mlir] [mlir][arith] Fold addi(x, not(x)) -> -1 (PR #212272)
Victor Perez
llvmlistbot at llvm.org
Tue Jul 28 08:12:19 PDT 2026
victor-eds wrote:
> I think having a specialized fast path for fold makes sense, especially since the canonicalization rewrite rules would likely need a one-use guard. But I'm wondering how often patterns like `~x + x` or `x + ~x` actually occur in realworld code? It seem this quire rare to me to have a dedicated fast-path
Good point: I guess it's rare as a direct pattern; nobody writes `x + ~x` by hand. Where it realistically happen is as the result of other transforms. A few concrete ways:
- Arithmetic complement idioms: source computes `-x - 1 + x`. `-x - 1` canonicalizes to `~x`, leaving `x + ~x`. LLVM instcombine folds `x + (-x - 1)` straight to then.
- Value numbering / copy propagation: an `x + ~y` becomes `x + ~x` once the compiler proves `y == x`.
So I don't think frequency is the strongest argument for it. The case is that it's cheap (only runs when an addi already has a not operand, and creates no new ops), it mirrors LLVM's InstructionSimplify fast path one-to-one (which MLIR fold is the analogue of), and folding to -1 can unlock downstream constant folding. It's also consistent with the rare-but-cheap folds arith already has, like `addi(subi(a, b), b) → a` and `subi(a, subi(a, b)) → b`. That said, I'm happy to defer it to the `^ -1` hoisting canonicalization instead if you'd rather keep the folder surface minimal. I don't have strong feelings here, I feel slightly inclined to keep the fold, but happy to defer :)
https://github.com/llvm/llvm-project/pull/212272
More information about the Mlir-commits
mailing list