Generalizes invariant handling to anything defined outside the Linalg op
(parameters and SSA computations). Fixes bug that was using parameter number
as tensor number.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thank you for the CL! The generated MLIR code looks good to me.
mlir/lib/Dialect/Linalg/Transforms/Sparsification.cpp | ||
---|---|---|
66 | A bit curious if union would be worth it. But then we'll have to have a nested union in a struct because kind is always there (and then bundle e0 and e1 together as one choice). So I think it's not worth the effort. |
mlir/lib/Dialect/Linalg/Transforms/Sparsification.cpp | ||
---|---|---|
66 | Coming from a classical C approach to compiler writing, that is always my instinct too! Once the dust settles we can always revisit our data structures and optimize, but I actually may use the "val" field elsewhere too (when implementing loop hoisting during sparse codegen, where we need a place to store the SSA value). So I think we will use this fields even for the others, making a struct better. |
mlir/lib/Dialect/Linalg/Transforms/Sparsification.cpp | ||
---|---|---|
66 | Can you add assertions for all the invariants in the constructor? I'd be worried about growing this struct beyond what it models right now: if the invariants have to get more complex it'll be worth revisiting this and model this as a class with better encapsulation. |
mlir/lib/Dialect/Linalg/Transforms/Sparsification.cpp | ||
---|---|---|
66 | Thanks Medhi. I just noticed this post-commit feedback. I will add assertions in the next CL. Also, I suspect this struct (and Merger class) may at some point migrate into their own utility file. It depends a bit on how many more "features" are required on the path to full bufferization :-) |
A bit curious if union would be worth it. But then we'll have to have a nested union in a struct because kind is always there (and then bundle e0 and e1 together as one choice). So I think it's not worth the effort.