[mlir][Vector] Fix a propagation bug with transfer_read
authorQuentin Colombet <quentin.colombet@gmail.com>
Mon, 5 Jun 2023 12:33:52 +0000 (14:33 +0200)
committerQuentin Colombet <quentin.colombet@gmail.com>
Mon, 5 Jun 2023 13:52:26 +0000 (15:52 +0200)
commit018d8ac974ff8ae6ef9bcda9990111ec84897107
tree2843a8e134d969ad833de6f87c997844be400a3c
parent27aea17fe061f9778bb1e8ff5fdf9fc0fb03abe1
[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
mlir/lib/Dialect/Vector/Transforms/VectorDistribute.cpp
mlir/test/Dialect/Vector/vector-warp-distribute.mlir