This is an archive of the discontinued LLVM Phabricator instance.

Support mixed types in vector.contract & lowerings
AbandonedPublic

Authored by Benoit on Oct 25 2021, 8:42 PM.

Details

Diff Detail

Event Timeline

Benoit created this revision.Oct 25 2021, 8:42 PM
Benoit requested review of this revision.Oct 25 2021, 8:42 PM

Generlly LGTM!
Thanks @Benoit

mlir/lib/Dialect/Vector/VectorOps.cpp
1828

can you make this "into" rather than "," to be consistent with other places in the IR ?

1838

if you keep "into" this would become something like:

parser.parseColonType(tLHS) || parser.parseComma() ||
      parser.parseType(tRHS) || parseOptionalKeyword("into") || parser.parseOptionalType(tRes)
```†
1850

then you'd have resType = tRes ? tRes : ... ;

mlir/lib/Dialect/Vector/VectorTransforms.cpp
245

we usually take the out of anon namespace and mark them static.
Also ///-prefixed doc plz.

252

some failure conditions on the promoted element type?
Then you'd return Value() and catch that above and fail with a readable error message.

815

Is this broadcast safe ?
It changes the underlying element type so I'd say no

824

maybe calling these promoteVector at a distance gets back on its feet with the Broadcast but I can't tell easily.
Please restructure the code so that the logic is less jumpy.

1170

createPromotedMul(... Type promotedElementType) + doc updates please.

1170

while you're at it, could you please use ImplicitLocOpBuilder and generally cleanup some of the things you're touching as you go ?

In the future this could become a helper function that does not need information that this is a rewriter.
Same comment for your promoteVector helper.

mlir/test/Dialect/Vector/vector-contract-transforms.mlir
2

disabled tests

Benoit abandoned this revision.Oct 26 2021, 9:33 AM

Thanks Nicolas for the review. Following more discussion with Nicolas and others, we are deciding to abandon this route and instead insert the ExtSIOp's on operands during vectorization, so that vector.contract doesn't need to support mixed types at all.

The primary motivation for this approach, which I think I grasped from Nicolas' explanations, is that that will make intermediate representation transformations simpler, as they won't need to worry about mixed types.

Transformations that convert vector.contract into intrinsics may then have to pattern-match ExtSI on operands, and that should not be too hard.

Linalg.generic's implementing any such computation have to have the extsi's in their basic block already, so what we are discussing here is merely saying that vectorization should preserve (vectorize) extsi's, instead of dropping them to feed source i8 values directly to vector.contract, as the custom transformation that I was concerned with was doing.