This revision restructures the calling of vector transforms to make it more flexible to ask for lowering through LLVM matrix intrinsics.
This also makes sure we bail out in degenerate cases (i.e. 1) in which LLVM complains about not being able to scalarize.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/VectorOps/VectorTransforms.cpp | ||
---|---|---|
955 | Can you expand the comment to describe the problem with LLVM? | |
mlir/test/lib/Transforms/TestVectorTransforms.cpp | ||
27 | Can you use pass options instead? |
mlir/include/mlir/Dialect/VectorOps/VectorOps.h | ||
---|---|---|
28 | What benefit do constructors bring in this instance? Once multiple options are available and they can be logically grouped and given a meaningful name we can provide static constructors that configure a set of options. We can also provide chaining semantics to have something like: VectorTransformsOptions().setX(true).setY(3) All these will make sense in the future but are premature until we have at least 3-5 flags + behaviors that must compound. | |
mlir/test/lib/Transforms/TestVectorTransforms.cpp | ||
27 | very cool! Done. |
mlir/include/mlir/Dialect/VectorOps/VectorOps.h | ||
---|---|---|
28 | Well, this was just a vague forward looking idea; with proper enums a constructor could read something like this VectorTransformOpions(ENABLE_LOWER_TO_LLVM_MATRIX, USE_THIS_AND_THAT) when passing it into a method without the need for a chain of setters. But given that we have one bool, the point is moot :-) | |
mlir/lib/Dialect/VectorOps/VectorTransforms.cpp | ||
956 | if this is really a for now, consider adding a TODO in addition to the bug links |
add a comment here to document the struct
(options for the vector transforms, or at least the contract populate method for now)