Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Wren, please note that bug https://bugs.llvm.org/show_bug.cgi?id=52303 was already taken by somebody else. I will reassign and coordinate with them, but please let's make sure we do not cause too many conflicts with external work while that is ongoing.
I more or less expected a CMakeLists.txt change too, but I guess ${MLIR_MAIN_INCLUDE_DIR}/mlir/ExecutionEngine takes care of that already
mlir/include/mlir/ExecutionEngine/SparseUtils.h | ||
---|---|---|
12 | Although I don't disagree, let's not put comments like this in the code. This situation is hard to solve since we are *generating* code that adheres to a certain API. | |
17 | move this line inside the macro ifdef | |
21 | empty line before this line | |
46 | Rather than saying "copy of", let's say that this enum mimics the SparseTensorEncodingAttr::DimLevelType (which is the source of truth) and its values should be kept consistent with that enum | |
54 | empty line after this line | |
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp | ||
79 | I assume that without the (uint32_t) cast is does not compile? | |
90 | I found the original way of testing a bit more readable than having this cast branch just to safe a few (hidden) casts. | |
mlir/lib/ExecutionEngine/SparseUtils.cpp | ||
662–693 | it was never pretty, but now with the extra lines this has become a lot larger |
mlir/lib/ExecutionEngine/SparseUtils.cpp | ||
---|---|---|
645 | wasn't this change to getNext() in one of your previous revisions? |
Heads up Wren.
It looks like https://reviews.llvm.org/D113043 will go in first, so you will need to (trivially) rebase against that name change
mlir/include/mlir/ExecutionEngine/SparseUtils.h | ||
---|---|---|
21 | Do we have a tool for enforcing this? I've just been following the usual mlir formatting/linting tool, but it didn't complain here. | |
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp | ||
79 | Yes, unfortunately. If one of the other casting styles is preferred for this circumstance, let me know | |
mlir/lib/ExecutionEngine/SparseUtils.cpp | ||
645 | I think it's still just shrapnel from the original rebase/landing glitch | |
662–693 | C++20 adds a using enum statement that would fix it; but for C++14 I'll have to think a bit more... |
mlir/include/mlir/ExecutionEngine/SparseTensorUtils.h | ||
---|---|---|
1 ↗ | (On Diff #384848) | SparseTensorUtils.h now ;-) |
14 ↗ | (On Diff #384848) | SPARSETENSORUTILS, here and below |
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp | ||
79 | Yes, in that case I believe that static_cast<> is preferred over the hold style C cast syntax. |
Nice progress! Ship it!
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp | ||
---|---|---|
92 | nit: LLVM style prefer no-braces if all branches are single statement |
Although I don't disagree, let's not put comments like this in the code.
The good part is that we share the enums ;-)
This situation is hard to solve since we are *generating* code that adheres to a certain API.
So it is very hard to enforce full API consistency with just headers.