This is an archive of the discontinued LLVM Phabricator instance.

[mlir][vector] Fold extract(broadcast) of same rank
ClosedPublic

Authored by antiagainst on Apr 7 2022, 6:22 AM.

Details

Summary

This case is handled in neither the folding or canonicalization
patterns. The folding pattern cannot generate new broadcast ops,
so it should be handled by the canonicalization pattern.

Diff Detail

Event Timeline

antiagainst created this revision.Apr 7 2022, 6:22 AM
Herald added a project: Restricted Project. · View Herald Transcript
antiagainst requested review of this revision.Apr 7 2022, 6:22 AM
ThomasRaoux added inline comments.Apr 7 2022, 8:32 AM
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1511

I would expect this case to be handled by foldExtractFromBroadcast.

It would be good to understand why this code didn't handle it:

static Value foldExtractFromBroadcast(ExtractOp extractOp) {
  Operation *defOp = extractOp.getVector().getDefiningOp();
  if (!defOp || !isa<vector::BroadcastOp, SplatOp>(defOp))
    return Value();
  Value source = defOp->getOperand(0);
  if (extractOp.getType() == source.getType())
    return source;
antiagainst marked an inline comment as done.Apr 7 2022, 9:09 AM
antiagainst added inline comments.
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1511

The fold interface cannot generate new ops. As shown by the test, if the broadcast src and extract dst has the same type, we may need to generate a new broadcast (from -> vector<1x8xf32> to -> vector<8xf32>). That's not supported per fold constraints.

antiagainst marked an inline comment as done.Apr 7 2022, 9:10 AM
antiagainst added inline comments.
mlir/lib/Dialect/Vector/IR/VectorOps.cpp
1511

... has the same rank...

ThomasRaoux accepted this revision.Apr 7 2022, 9:56 AM
This revision is now accepted and ready to land.Apr 7 2022, 9:56 AM
This revision was automatically updated to reflect the committed changes.