This is an archive of the discontinued LLVM Phabricator instance.

[mlir][sparse] add more dimension level types and properties
ClosedPublic

Authored by aartbik on Aug 29 2022, 4:08 PM.

Details

Summary

We recently removed the singleton dimension level type (see the revision
https://reviews.llvm.org/D131002) since it was unimplemented but also
incomplete (properties were missing). This revision add singleton back as
extra dimension level type, together with properties ordered/not-ordered
and unique/not-unique. Even though still not lowered to actual code, this
provides a complete way of defining many more sparse storage schemes (in
the long run, we want to support even dimension level types and properties
using the additional extensions proposed in [Chou]).

Note that the current solution of using suffixes for the properties is not
ideal, but keeps the extension relatively simple with respect to parsing and
printing. Furthermore, it is rather consistent with the TACO implementation
which uses things like Compressed-Unique as well. Nevertheless, we probably
want to separate dimension level types from properties when we add more types
and properties.

Diff Detail

Event Timeline

aartbik created this revision.Aug 29 2022, 4:08 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 29 2022, 4:08 PM
aartbik requested review of this revision.Aug 29 2022, 4:08 PM

While using string suffixes is ugly for now, I don't think it's too bad. That is, in the long term I think we'll want to replace the string-based specification of dimleveltypes with an AST-based specification. Whenever (if ever) that happens, then we can treat the variable properties as arguments/attributes of the base dlt; for example compressed { nu, no } (or whatever custom syntax we prefer). Whereas if some dlt fixes a particular property (e.g., dense fixes both the sortedness and uniqueness properties), then it wouldn't take an argument for the property since it would have it as an intrinsic attribute instead.

While using string suffixes is ugly for now, I don't think it's too bad. That is, in the long term I think we'll want to replace the string-based specification of dimleveltypes with an AST-based specification. Whenever (if ever) that happens, then we can treat the variable properties as arguments/attributes of the base dlt; for example compressed { nu, no } (or whatever custom syntax we prefer). Whereas if some dlt fixes a particular property (e.g., dense fixes both the sortedness and uniqueness properties), then it wouldn't take an argument for the property since it would have it as an intrinsic attribute instead.

Agreed. And yes, we want to move towards something like "compressed { nu, no }" in the longer run.
This will be very similar to the C++ implementation in TACO, where properties are passed into the format construction:

ModeFormat::Singleton(ModeFormat::NOT_UNIQUE)
aartbik updated this revision to Diff 456496.Aug 29 2022, 4:41 PM

minor edits

aartbik updated this revision to Diff 456508.Aug 29 2022, 6:07 PM

fixed typo

Peiming added a comment.EditedAug 30 2022, 10:06 AM

I am wondering how long will current string-encoding stand? Agree with Wren that current implementation is ugly (and not extensible)

Peiming accepted this revision.Aug 30 2022, 10:14 AM
This revision is now accepted and ready to land.Aug 30 2022, 10:14 AM

I am wondering how long will current string-encoding stand? Agree with Wren that current implementation is ugly (and not extensible)

We can work on beautifying the parsing/printing/encoding next. This revision, however, will get the ball rolling on supporting singleton properly within sparse compiler itself.

aartbik updated this revision to Diff 456714.Aug 30 2022, 10:21 AM

rebased with main

This revision was landed with ongoing or failed builds.Aug 30 2022, 10:38 AM
This revision was automatically updated to reflect the committed changes.