Introduces the expand and compress operations to the Vector dialect
(important memory operations for sparse computations), together
with a first reference implementation that lowers to the LLVM IR
dialect to enable running on CPU (and other targets that support
the corresponding LLVM IR intrinsics).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/integration_test/Dialect/Vector/CPU/test-expand.mlir | ||
---|---|---|
43 | I'm not sure what the MLIR team philosophy is on this, but in test code that creates test inputs (like everything up to this point in this case), I find myself carefully reading that code to make sure I understand what input test values are expected to be, which seems to be besides the point. Would it make sense to print these values and //CHECK them, so that reviewers don't have to figure out what the inputs are, and that they are correct? (And it serves as additional testing for the "boilerplate" stuff, just in case... |
mlir/integration_test/Dialect/Vector/CPU/test-expand.mlir | ||
---|---|---|
43 | Good question. I sometimes print the test values also (see some other tests), but indeed not in this case. I am not sure we have an established philosophy yet, but in the long run, I am thinking of replacing setup code like this with something simpler, like |
Ai, I need to rebase/adjust my tests with the new llvm type format that Alex just checked in. Stay tuned.....
I'm not sure what the MLIR team philosophy is on this, but in test code that creates test inputs (like everything up to this point in this case), I find myself carefully reading that code to make sure I understand what input test values are expected to be, which seems to be besides the point. Would it make sense to print these values and //CHECK them, so that reviewers don't have to figure out what the inputs are, and that they are correct? (And it serves as additional testing for the "boilerplate" stuff, just in case...