Paying off some technical debt in VectorOps, where I introduced a special
op for a fused accumulator into reduction to avoid some issues around
printing and parsing an optional accumulator. This CL merges the two
into one op again and does things the right way (still would be nice
to have "assemblyFormat" for optional operands though....).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Great, thanks Aart!
I'll use this to ping again on the broadcast progressive lowering, was this something you wanted to offload as an intro task IIRC ?
mlir/lib/Dialect/VectorOps/VectorOps.cpp | ||
---|---|---|
98 | Re assembly format, file a bug for @rriddle linking to this diff? |
mlir/lib/Dialect/VectorOps/VectorOps.cpp | ||
---|---|---|
98 | It already does: https://mlir.llvm.org/docs/OpDefinitions/#optional-groups |
mlir/lib/Dialect/VectorOps/VectorOps.cpp | ||
---|---|---|
98 | Ah, very interesting! The customer parsing/printing here has a minor advantage of printing less type information (since most of it is inferred), but that is good to keep in mind. Thanks. |
mlir/lib/Dialect/VectorOps/VectorOps.cpp | ||
---|---|---|
98 | I think the only problem you will run into is with inferring the type of the optional operand. |
mlir/lib/Dialect/VectorOps/VectorOps.cpp | ||
---|---|---|
98 | The assembly format can already infer types in a majority of cases. I don't think this explicit case is handled right now, though it should be easy to support. (i.e. inferring the type of an optional operand) |
Re assembly format, file a bug for @rriddle linking to this diff?
Another way, if variadic is more tricky to impl automatically (because of say combinatorial effects with variadic operands), could be to allow multiple declarative forms and a simple convention on optional arg ordering?