[Mlir-commits] [mlir] [mlir][sparse] Fix crash in sparsification when disjunctive op has sparse operand (PR #184599)

[llvmlistbot at llvm.org]

llvmbot wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-mlir

Author: Mehdi Amini (joker-eph)

<details>
<summary>Changes</summary>

When `buildTensorExp` processes a disjunctive binary op (add, sub, or, xor), it returned `hasSparseDep = disjSpVals = xSpVals && ySpVals` — true only when *both* operands reference a sparse tensor. For an expression like `math.exp(arith.subf(sparse_in, dense_in))`, the inner `arith.subf` has `xSpVals=true, ySpVals=false` → `disjSpVals=false`, incorrectly satisfying the `\!hasSparseDep` condition used to create a `kDenseOp` wrapper node.

The spurious `kDenseOp` inherits the disjunctive lattice of its child (`kSubF`), producing an "arg1-only" lattice point with an undefined level type at the loop being generated. `optimizeSet` does not eliminate this point because the XOR with the base point contains a sparse bit (from `sparse_in`). When code generation reaches this lattice point, the synthetic-tensor iterator is used uninitialized (null cursor), causing a crash in `TrivialIterator::derefImpl`.

Fix: use `conjSpVals = xSpVals || ySpVals` (any-sparse) for all disjunctive ops in `buildTensorExp`. Since the return value's `hasSparseDep` field is only consumed internally within `buildTensorExp` for the `kDenseOp` creation check, this is safe. With the fix, any expression containing a sparse-tensor operand prevents `kDenseOp` wrapping, causing `initTensorExp` to return failure and `matchAndRewrite` to gracefully leave the `linalg.generic` unmodified.

Fixes #<!-- -->114855

---
Full diff: https://github.com/llvm/llvm-project/pull/184599.diff


2 Files Affected:

- (modified) mlir/lib/Dialect/SparseTensor/Utils/Merger.cpp (+8-9) 
- (modified) mlir/test/Dialect/SparseTensor/unsparsifiable_dense_op.mlir (+32) 


``````````diff

``````````

</details>


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