This is an archive of the discontinued LLVM Phabricator instance.

[mlir][NFC] Refactor linalg vectorization for reduction ops
ClosedPublic

Authored by ThomasRaoux on Oct 14 2021, 10:47 AM.

Details

Summary

Emit reduction during op vectorization instead of doing it when creating the transfer write. This allow us to not broadcast output arguments for reduction initial value.

Diff Detail

Event Timeline

ThomasRaoux created this revision.Oct 14 2021, 10:47 AM
ThomasRaoux requested review of this revision.Oct 14 2021, 10:47 AM
pifon2a accepted this revision.Oct 14 2021, 11:20 AM
This revision is now accepted and ready to land.Oct 14 2021, 11:20 AM
mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
389

This "fused" loop structure feels quite unnatural.
Maybe they are not possible in practice but it looks like there is a possible path where one operand passes all the checks and then we hit return; that would def. sound fishy.

I'd rather structure the code like:

SmallVector<Value> reducedValues, operands;
for (Value operand : ...) {
...
  if (reducedValue) {
    reducedValues.push_back(reducedValue);
    operands.push_back(operand);
  } 
}
assert(reducedValues.size() <= 1);
... etc
403

"reduce only if needed" sounds exactly like reduceIfNeeded.
I understand the impl changes as we do it eagerly instead of late.
Can we keep the function name and move the modified impl in there ?

405

is this check only for avoid interfering with the specific path of contraction vectorization?
If so it starts to feel like we want to push on the missing canonicalizations / foldings and drop such "interference avoidance checks".

Thanks for fixing!
Let's just clean the code a bit and land this.

Also, this is really not NFC, we are generating better IR here.

Address review comments.

ThomasRaoux added inline comments.Oct 14 2021, 1:10 PM
mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
389

Makes sense, I broke the loop up as suggested.

403

Moved the logic in reduceIfNeeded function

405

Yes, I can take a look at that sometime soon.

This revision was landed with ongoing or failed builds.Oct 14 2021, 1:38 PM
This revision was automatically updated to reflect the committed changes.
dcaballe added inline comments.Oct 14 2021, 6:08 PM
mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
397

reductionOps may contain multiple ops. Actually, I think we are not even using reductionOps anywhere here? I think this is bringing back the problem I was trying to solve with the matchReduction utility: detecting reductions with multiple ops.

ThomasRaoux added inline comments.Oct 14 2021, 7:00 PM
mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
397

Right, we currently check that there is only a single op in matchReduction otherwise it fails. This wouldn't work otherwise indeed, maybe we need an assert. Here op will be the same as reductionOps[0], probably worth an assert too.