Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h | ||
---|---|---|
181 | Should be "properties", since there's more than one of them. Though I'm a bit hesitant about the current API. Since it returns DimLevelType, I interpret that as promising that the result is always a valid/defined DLT. That promise is fulfilled for all the current DLTs, since we don't have any DLTs which don't support the ordered+unique variant; though I'm not sure if we want to promise that that'll remain the case going forward. This is the same reason why I've only had predicates for checking properties, rather than having functions to set/clear them. That said, this is also something that @pgavin was wanting a while back. So I see two ways forward. (1) We could have this function return uint8_t, which makes it clear that it's just a bitfield and not necessarily a valid DLT. (2) Or we could leave the type as-is, then explicitly document the promise, and make sure to honor the promise as we add new DLTs going forward. | |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
348 | Why are the ordered+unique DLTs considered "canonical" whereas the unordered and nonunique ones aren't? That is, I don't think "canonical" is really the right name for what this function does. I think it would be better to rename this function to something more like normalizeEncodingForStorageSpecifierType, or similar |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
---|---|---|
348 | Yes, normalize feels more right |
Should be "properties", since there's more than one of them.
Though I'm a bit hesitant about the current API. Since it returns DimLevelType, I interpret that as promising that the result is always a valid/defined DLT. That promise is fulfilled for all the current DLTs, since we don't have any DLTs which don't support the ordered+unique variant; though I'm not sure if we want to promise that that'll remain the case going forward. This is the same reason why I've only had predicates for checking properties, rather than having functions to set/clear them.
That said, this is also something that @pgavin was wanting a while back. So I see two ways forward. (1) We could have this function return uint8_t, which makes it clear that it's just a bitfield and not necessarily a valid DLT. (2) Or we could leave the type as-is, then explicitly document the promise, and make sure to honor the promise as we add new DLTs going forward.