This is an archive of the discontinued LLVM Phabricator instance.

[mlir][sparse] lower number of entries op to actual code
ClosedPublic

Authored by aartbik on Oct 20 2022, 4:09 PM.

Details

Summary

works both along runtime path and pure codegen path

Diff Detail

Event Timeline

aartbik created this revision.Oct 20 2022, 4:09 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2022, 4:09 PM
aartbik requested review of this revision.Oct 20 2022, 4:09 PM
wrengr added inline comments.Oct 20 2022, 4:18 PM
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp
760

Is there any better way to abstract over this? (to avoid magic numbers / ensure it stays in sync with the struct definition)

mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
952–956

Should factor out a genSparseValuesCall function, to deduplicate this code and the version in SparseTensorToValuesConverter::matchAndRewrite

aartbik updated this revision to Diff 469405.Oct 20 2022, 4:35 PM

rebased against main

aartbik marked 2 inline comments as done.Oct 20 2022, 4:47 PM
aartbik added inline comments.
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp
760

Yeah, that is a good suggestion, since the -2 has bitten me before. Added a general util for MemSizes field

mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
952–956

That is really just two lines of code and will break the nice symmetry with the other "getters".
Is it worth it?

aartbik updated this revision to Diff 469410.Oct 20 2022, 4:52 PM
aartbik marked 2 inline comments as done.

added dimSizes index util (to avoid magic subtractions all over the place)

aartbik updated this revision to Diff 469413.Oct 20 2022, 4:58 PM

dimSizes -> memSizes of course

wrengr added inline comments.Oct 20 2022, 5:01 PM
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
952–956

The biggest reason to share it is to avoid the "magic constants" problem re the 15 and "sparseValues". Most of the other genFooCall functions are similarly short, but exist to address the same maintenance concerns. Perhaps there won't be any other places that use it in the future, but whenever I see the same magic constants more than once that's a warning flag for me, especially when they're strings :)

I don't quite follow what you mean about symmetry with other getters, but this would give symmetry with the other genFooCall functions.

aartbik marked an inline comment as done.Oct 20 2022, 5:06 PM
aartbik added inline comments.
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
952–956

Ok (by symmetric I meant that all SparseTensorToXXXConverters looked very similar and this would break that, but not a big deal).

The <15> is a good point [is there a templating way of getting rid of the need for that, btw, it seems we could strlen somehow at compile-time?!

aartbik updated this revision to Diff 469437.Oct 20 2022, 5:44 PM
aartbik marked an inline comment as done.

refactored out getValues call

wrengr added inline comments.Oct 20 2022, 6:31 PM
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
952–956

by symmetric I meant that all SparseTensorToXXXConverters

Gotcha. Yeah, when looking over the code a while back for the Enums refactoring, I saw a few places where the setup for createFuncCall wasn't abstracted into a genFooCall wrapper; but since they were the single place the given function was called, I didn't bother writing up a CL to add the wrappers (because definitely not worth it if there's only one callsite :)

is there a templating way of getting rid of the need for that, btw, it seems we could strlen somehow at compile-time?!

It's doable, but I'm not sure it's worth the code it'd take to do it. Last time I thought about it, the simplest way I could come up with was to store the base-name string literal as a global constexpr, and then have some macro for threading that constexpr into both the size and the value; i.e., something like:

static constexpr const char *kFooBaseFunctionName = "foo";
static constexpr unsigned kMaxLenPrimaryTypeFunctionSuffix = 3;
...
# define PRIMARYTYPE_FUNCTION_NAME(VAR, BASE, ETP) \
    SmallString<std::strlen(BASE) + kMaxLenPrimaryTypeFunctionSuffix> VAR{BASE, primaryTypeFunctionSuffix(ETP)};
...
static Value genFooCall(...) {
    PRIMARYTYPE_FUNCTION_NAME(name, kFooBaseFunctionName, elemTp)
    ...
}

Of course we'd also need to define our own version of strlen since std::strlen isn't constexpr. (But that's easy enough to do, since this is compile-time and the strings are short, therefore performance isn't much of a concern.)

We could probably convert the macro into a proper template by using tricks similar to https://en.cppreference.com/w/cpp/types/integral_constant; i.e., so we could define the moral equivalent of:

template<string BaseName>
class PrimaryTypeFunctionName {
  SmallString<strlen(BaseName) + kMaxLenPrimaryTypeFunctionSuffix> name;
public:
  PrimaryTypeFunctionName(Type elemTp) : name(BaseName, primaryTypeFunctionSuffix(elemTp)) {}
  StringRef getName() const { return name; }
}

Then we could just use it à la PrimaryTypeFunctionName<"foo"> name(elemTp);. Though I'm not sure how close to this ideal we could really get. Afterall, the whole point of using SmallString was to allocate these small buffers directly on the stack; so we wouldn't want to break that.

There might be something else in the STL (or LLVM/MLIR utils) which can help simplify this metaprogramming, but I didn't see anything last time I thought about all this.

aartbik marked an inline comment as done.Oct 21 2022, 9:19 AM
aartbik added inline comments.
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
952–956

It's doable, but I'm not sure it's worth the code it'd take to do it.

Neat! Thanks for figuring that out. I agree with you that this is probably not worth the extra machinery, given that we only have a handful of such methods.

Peiming accepted this revision.Oct 21 2022, 10:40 AM
Peiming added inline comments.
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorConversion.cpp
934

Neat, I was worrying whether there is an implicit copy here, but seems runtime library just copy the pointer ;-)

This revision is now accepted and ready to land.Oct 21 2022, 10:40 AM
aartbik updated this revision to Diff 469682.Oct 21 2022, 10:44 AM
aartbik marked an inline comment as done.

rebased with main

This revision was landed with ongoing or failed builds.Oct 21 2022, 10:48 AM
This revision was automatically updated to reflect the committed changes.