When generating code to add an element to SparseTensorCOO (e.g., when doing dense=>sparse conversion), we used to check for nonzero values on the runtime side, whereas now we generate MLIR code to do that check.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
A bunch of integration tests are currently failing. I'll look into those and post an update tomorrow (or later this week).
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp | ||
---|---|---|
182 | this seems the right decision right, so no TODO required? | |
188 | note that there is a rewriter.getZeroAttr(vtp) utility that works for both FP and INT (doing the same under water). Perhaps you can simply start with Value zero = rewriter.getZeroAttr(vtp); | |
189 | Note that LLVM style (and thus clang-tidy) prefers if (x) return... if (y) return ... <anything else> instead of the else-s | |
193 | so no else, but just unreachable |
As for the tests, I have several CHECK tests that verify the IR is as we expect for the conversion, e.g.
func @sparse_convert_1d(%arg0: tensor<?xi32>) -> tensor<?xi32, #SparseVector> {
%0 = sparse_tensor.convert %arg0 : tensor<?xi32> to tensor<?xi32, #SparseVector> return %0 : tensor<?xi32, #SparseVector>
}
In this case, you will need to add the "if val != 0" to the pattern in the CHECKs.
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorPasses.cpp | ||
---|---|---|
1 | Ah, good catch. Can you also fix the spares -> sparse while you are on this line ;-) |
mlir/lib/ExecutionEngine/SparseUtils.cpp | ||
---|---|---|
554–555 | please rebase to main. you will most likely get conflicts on this file (due to the ABI fixes that just went in), but it will be extremely easy to resolve since you just need to find the two lines where you deleted this return ;-) |
Is this rebased with a "pulled" mainline? I don't seen the memref ABI fixes in this revision yet?
No big deal, but better to rebase now then have failed merge due to conflicts later ;-)
this seems the right decision right, so no TODO required?