This patch abstracts sparse tensor memory scheme into a SparseTensorDescriptor class. Previously, the field accesses are performed in a relatively error-prone way, this patch hides the hairy details behind a SparseTensorDescriptor class to allow users access sparse tensor fields in a more cohesive way.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/SparseTensor/Transforms/CodegenUtils.cpp | ||
---|---|---|
99 | This description describes the layout and thus drives all the code. |
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp | ||
---|---|---|
172 | A better way to create PushBackOp can be PushBackOp(builder, loc, descriptor, fidx, value), which is more clear and can be read as "push a value into the sparse tensor descriptor at the given field index). But it would require us to put SparseTensorDescriptor to a publicly available place (and I am not sure whether it is wanted). |
mlir/lib/Dialect/SparseTensor/Transforms/CodegenUtils.h | ||
---|---|---|
336 | I think this line should not be here? Copied from somewhere else? | |
357 | relying *on* ad-hoc | |
377 | , and a | |
387 | an array | |
390 | layouted -> laid out? (I think that is the proper english, not sure though...) | |
412 | to restore (no d) | |
437 | it feels like we have many more getters than we really need? | |
441 | Although this solution is much better at information hiding than the original, we now need to scan each time for every field query. Although this is never very deep (rank bounded), it is still a bit wasteful. Can we avoid this by precomputing offsets per dimenison? | |
448 | this feels very convoluted? why do we need a dim for a value query? | |
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp | ||
256 | note that this works for now, but we actually planned to implement a heuristic here, which will need to scan the ranks + level types again | |
278 | continue | |
391 | yeah, agreed, this made more sense in the original but the alternative is to copy and create a fully new array.... |
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp | ||
---|---|---|
256 | Then, you can have another foreach before this to compute the heuristic. |
It is not flang specific issue, though. The following gcc buildbot fails: https://lab.llvm.org/buildbot/#/builders/160/builds/13724
The build log seems to directly point to your code (https://lab.llvm.org/buildbot/#/builders/160/builds/13724/steps/5/logs/stdio):
In file included from ../llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/SparseBufferRewriting.cpp:14: ../llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/CodegenUtils.h:396:13: error: explicit specialization in non-namespace scope ‘class mlir::sparse_tensor::SparseTensorDescriptorImpl<mut>’ 396 | template <> | ^ ../llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/CodegenUtils.h:397:10: error: too few template-parameter-lists 397 | struct ArrayStorage<false> { | ^~~~~~~~~~~~~~~~~~~ ../llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/CodegenUtils.h:401:13: error: explicit specialization in non-namespace scope ‘class mlir::sparse_tensor::SparseTensorDescriptorImpl<mut>’ 401 | template <> | ^ ../llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/CodegenUtils.h:402:10: error: too few template-parameter-lists 402 | struct ArrayStorage<true> { | ^~~~~~~~~~~~~~~~~~
@Peiming : I reverted your change because it broke multiple buildbots - windows and gcc included. I see that you've re-committed it. Did you make sure to address all three build breaks that were reported including the one @vzakhari pointed out? In cases like this, please make sure NOT to recommit your changes without making sure that all build breaks are addressed as it is disruptive to have buildbots that are broken especially when a change is identified as the source.
Yes, of course. I haven't push the code, waiting the pre-merge windows build to finish.
I think this line should not be here? Copied from somewhere else?