[all-commits] [llvm/llvm-project] 018d8a: [mlir][Vector] Fix a propagation bug with transfer...

[qcolombet via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 018d8ac974ff8ae6ef9bcda9990111ec84897107
      https://github.com/llvm/llvm-project/commit/018d8ac974ff8ae6ef9bcda9990111ec84897107
  Author: Quentin Colombet <quentin.colombet at gmail.com>
  Date:   2023-06-05 (Mon, 05 Jun 2023)

  Changed paths:
    M mlir/lib/Dialect/Vector/Transforms/VectorDistribute.cpp
    M mlir/test/Dialect/Vector/vector-warp-distribute.mlir

  Log Message:
  -----------
  [mlir][Vector] Fix a propagation bug with transfer_read

In the vector distribute patterns, we used to move
`vector.transfer_read`s out of `vector.warp_execute_on_lane0`s
irrespectively of how they were defined.

This could create transfer_read operations that would read values from
within the warpOp's body from outside of the body.
E.g.,
```
warpop {
  %defined_in_body
  %read = transfer_read %defined_in_body
  vector.yield %read
}
```
=>
```
warpop {
  %defined_in_body
  vector.yield ...
}
// %defined_in_body is referenced outside of its scope.
%read = transfer_read %defined_in_body
```

The fix consists in checking that all the values feeding the new
`transfer_read` are defined outside of warpOp's body.

Note: We could do this check before creating any operation, but that would
mean knowing what `affine::makeComposedAffineApply` actually do. So the
current fix is a trade off of coupling the implementations of this
propagation and `makeComposedAffineApply` versus compile time.

Differential Revision: https://reviews.llvm.org/D152149