This is an archive of the discontinued LLVM Phabricator instance.

[mlir][sparse] Factoring magic numbers into a header
ClosedPublic

Authored by wrengr on Nov 1 2021, 2:06 PM.

Diff Detail

Event Timeline

wrengr created this revision.Nov 1 2021, 2:06 PM
wrengr requested review of this revision.Nov 1 2021, 2:06 PM
wrengr edited the summary of this revision. (Show Details)Nov 1 2021, 2:07 PM
wrengr updated this revision to Diff 383886.Nov 1 2021, 2:14 PM

Removing notes to self

wrengr edited the summary of this revision. (Show Details)Nov 1 2021, 2:15 PM

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.
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.

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
anyway to avoid that?

aartbik added inline comments.Nov 1 2021, 10:45 PM
mlir/lib/ExecutionEngine/SparseUtils.cpp
645

wasn't this change to getNext() in one of your previous revisions?
is that lost again? or do we need to rebase this change to main?

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

wrengr updated this revision to Diff 384846.Nov 4 2021, 12:29 PM
wrengr marked 8 inline comments as done.

Addressing comments

wrengr added inline comments.Nov 4 2021, 12:32 PM
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...

wrengr updated this revision to Diff 384848.Nov 4 2021, 12:39 PM

Crossing off my todo

wrengr edited the summary of this revision. (Show Details)Nov 4 2021, 1:29 PM
aartbik added inline comments.Nov 5 2021, 10:28 AM
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.

wrengr updated this revision to Diff 385178.Nov 5 2021, 1:45 PM
wrengr marked 3 inline comments as done.
wrengr edited the summary of this revision. (Show Details)

Updating casting style. And fixing SparseUtils => SparseTensorUtils renaming.

aartbik accepted this revision.Nov 5 2021, 2:21 PM

Nice progress! Ship it!

mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
92

nit: LLVM style prefer no-braces if all branches are single statement

This revision is now accepted and ready to land.Nov 5 2021, 2:21 PM
wrengr updated this revision to Diff 385204.Nov 5 2021, 3:16 PM
wrengr marked an inline comment as done.

LLVM style

wrengr updated this revision to Diff 385205.Nov 5 2021, 3:17 PM

rebased

This revision was automatically updated to reflect the committed changes.