[mlir][vector] Prevent incorrect vector.transfer_{read|write} hoisting #66930

banach-space · 2023-09-20T17:19:19Z

At the moment, hoistRedundantVectorTransfers would hoist the vector.transfer_read/vector.transfer_write pair in this function:

func.func @no_hoisting_write_to_memref(%rhs: i32, %arg1: vector<1xi32>) {
  %c0_i32 = arith.constant 0 : i32
  %c0 = arith.constant 0 : index
  %c1 = arith.constant 1 : index
  %c4 = arith.constant 4 : index
  %c20 = arith.constant 20 : index
  %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32>
  %cast = memref.cast %alloca : memref<1x1x2xi32> to memref<1x1x2xi32>
  %collapsed_1 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
  scf.for %_ = %c0 to %c20 step %c4 {
    %collapsed_2 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
    %lhs = vector.transfer_read %collapsed_1[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %acc = vector.transfer_read %collapsed_2[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %op = vector.outerproduct %lhs, %rhs, %acc {kind = #vector.kind<add>} : vector<1xi32>, i32
    vector.transfer_write %op, %collapsed_1[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32>
  }
  return
}

as follows:

  func.func @no_hoisting_write_to_memref(%arg0: i32, %arg1: vector<1xi32>) {
    %c0_i32 = arith.constant 0 : i32
    %c0 = arith.constant 0 : index
    %c4 = arith.constant 4 : index
    %c20 = arith.constant 20 : index
    %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32>
    %collapse_shape = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
    %collapse_shape_0 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
    %0 = vector.transfer_read %collapse_shape[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %1 = vector.transfer_read %collapse_shape_0[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %2 = scf.for %arg2 = %c0 to %c20 step %c4 iter_args(%arg3 = %0) -> (vector<1xi32>) {
      %3 = vector.outerproduct %arg3, %arg0, %1 {kind = #vector.kind<add>} : vector<1xi32>, i32
      scf.yield %3 : vector<1xi32>
    }
    vector.transfer_write %2, %collapse_shape[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32>
    return
  }

This is not safe. While one argument for vector.outerproduct (%rhs from the original loop) is correctly being forwarded via iter_args, the other one (%acc from the original loop) is not.

This patch disables hoisting in cases where the source of "candidate" vector.transfer_read aliases with some other memref. A more generic approach would be to make sure that all values are correctly forwarded via iter_args, but that would require involving alias analysis.

[1] Based on iree-org/iree#14994.

llvmbot · 2023-09-20T17:20:24Z

@llvm/pr-subscribers-mlir-linalg

@llvm/pr-subscribers-mlir

Changes

Extracted from iree-org/iree#14994. This is a
draft to facilitate a discussion on the right approach for this.

Full diff: https://github.com/llvm/llvm-project/pull/66930.diff

2 Files Affected:

(modified) mlir/lib/Dialect/Linalg/Transforms/Hoisting.cpp (+4)
(modified) mlir/test/Dialect/Linalg/hoisting.mlir (+34)

diff --git a/mlir/lib/Dialect/Linalg/Transforms/Hoisting.cpp b/mlir/lib/Dialect/Linalg/Transforms/Hoisting.cpp
index 7c6639304d97c58..68afc3f0649588f 100644
--- a/mlir/lib/Dialect/Linalg/Transforms/Hoisting.cpp
+++ b/mlir/lib/Dialect/Linalg/Transforms/Hoisting.cpp
@@ -152,6 +152,10 @@ void mlir::linalg::hoistRedundantVectorTransfers(func::FuncOp func) {
           transferRead.getPermutationMap() != transferWrite.getPermutationMap())
         return WalkResult::advance();
 
+      // TODO: Is this the right fix?
+      if (!transferRead.use_empty())
+        return WalkResult::advance();
+
       // TODO: may want to memoize this information for performance but it
       // likely gets invalidated often.
       DominanceInfo dom(loop);
diff --git a/mlir/test/Dialect/Linalg/hoisting.mlir b/mlir/test/Dialect/Linalg/hoisting.mlir
index e25914620726b9b..ff1ff33ea7d1cd0 100644
--- a/mlir/test/Dialect/Linalg/hoisting.mlir
+++ b/mlir/test/Dialect/Linalg/hoisting.mlir
@@ -827,3 +827,37 @@ transform.sequence failures(propagate) {
   transform.structured.hoist_redundant_vector_transfers %0
     : (!transform.any_op) -> !transform.any_op
 }
+
+// -----
+
+// Regression test - the `vector.transfer_read`/`vector.transfer_write` pair
+// reads/writes to a memref, so it re-uesed in every iteration. Hoisting this
+// pair would change the semantics of this loop.
+
+// CHECK-LABEL:  func.func @no_hoisting_collapse_shape_2
+//       CHECK:    scf.for {{.*}} {
+//       CHECK:      vector.transfer_read
+//       CHECK:      vector.transfer_write
+
+func.func @no_hoisting_write_to_memref(%arg0: i32, %arg1: vector<1xi32>) {
+  %c0_i32 = arith.constant 0 : i32
+  %c0 = arith.constant 0 : index
+  %c4 = arith.constant 4 : index
+  %c20 = arith.constant 20 : index
+  %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x1xi32>
+  scf.for %_ = %c0 to %c20 step %c4 {
+    %collapsed = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x1xi32> into memref<1xi32>
+    %10 = vector.transfer_read %collapsed[%c0], %c0_i32 {in_bounds = [true]} : memref<1xi32>, vector<1xi32>
+    %17 = vector.outerproduct %arg1, %arg0, %10 {kind = #vector.kind<add>} : vector<1xi32>, i32
+    vector.transfer_write %17, %collapsed[%c0] {in_bounds = [true]} : vector<1xi32>, memref<1xi32>
+  }
+  return
+}
+
+transform.sequence failures(propagate) {
+^bb1(%arg1: !transform.any_op):
+  %0 = transform.structured.match ops{["func.func"]} in %arg1
+    : (!transform.any_op) -> !transform.any_op
+  transform.structured.hoist_redundant_vector_transfers %0
+    : (!transform.any_op) -> !transform.any_op
+}

banach-space · 2023-09-20T17:31:09Z

This is effectively a follow-up of #65770. I'm not sure what the right solution should be - what I am proposing "breaks" the hoist_vector_transfer_pairs test. However, I'm think that hoisting that particular pair of vector.transfer_read/vector.transfer_write is not safe:

  scf.for %i = %lb to %ub step %step {
    scf.for %j = %lb to %ub step %step {
      %r0 = vector.transfer_read %memref1[%c0, %c0], %cst: memref<?x?xf32>, vector<1xf32>
      %r1 = vector.transfer_read %memref0[%i, %i], %cst: memref<?x?xf32>, vector<2xf32>
      %r2 = vector.transfer_read %memref2[%c0, %c0], %cst: memref<?x?xf32>, vector<3xf32>
      %r3 = vector.transfer_read %memref3[%c0, %c0], %cst: memref<?x?xf32>, vector<4xf32>
      "some_crippling_use"(%memref4) : (memref<?x?xf32>) -> ()
      %r4 = vector.transfer_read %memref4[%c0, %c0], %cst: memref<?x?xf32>, vector<5xf32>
      %r5 = vector.transfer_read %memref5[%c0, %c0], %cst: memref<?x?xf32>, vector<6xf32>
      "some_crippling_use"(%memref5) : (memref<?x?xf32>) -> ()
      %u0 = "some_use"(%r0) : (vector<1xf32>) -> vector<1xf32>
      %u1 = "some_use"(%r1) : (vector<2xf32>) -> vector<2xf32>
      %u2 = "some_use"(%memref2, %r2) : (memref<?x?xf32>, vector<3xf32>) -> vector<3xf32>
      %u3 = "some_use"(%r3) : (vector<4xf32>) -> vector<4xf32>
      %u4 = "some_use"(%r4) : (vector<5xf32>) -> vector<5xf32>
      %u5 = "some_use"(%r5) : (vector<6xf32>) -> vector<6xf32>
      vector.transfer_write %u0, %memref1[%c0, %c0] : vector<1xf32>, memref<?x?xf32>
      vector.transfer_write %u1, %memref0[%i, %i] : vector<2xf32>, memref<?x?xf32>
      vector.transfer_write %u2, %memref2[%c0, %c0] : vector<3xf32>, memref<?x?xf32>
      vector.transfer_write %u3, %memref3[%c0, %c0] : vector<4xf32>, memref<?x?xf32>
      vector.transfer_write %u4, %memref4[%c0, %c0] : vector<5xf32>, memref<?x?xf32>
      vector.transfer_write %u5, %memref5[%c0, %c0] : vector<6xf32>, memref<?x?xf32>
      "some_crippling_use"(%memref3) : (memref<?x?xf32>) -> ()
    }
    "unrelated_use"(%memref0) : (memref<?x?xf32>) -> ()
  }

In particular:

      %r1 = vector.transfer_read %memref0[%i, %i], %cst: memref<?x?xf32>, vector<2xf32>
      %u1 = "some_use"(%r1) : (vector<2xf32>) -> vector<2xf32>
      vector.transfer_write %u1, %memref0[%i, %i] : vector<2xf32>, memref<?x?xf32>

While %i is loop-invariant (which could hint that hoisting would be safe), the value of %r1 could actually change between the 1st and the 2nd iteration.

nicolasvasilache · 2023-09-21T12:01:00Z

In particular:
      %r1 = vector.transfer_read %memref0[%i, %i], %cst: memref<?x?xf32>, vector<2xf32>
      %u1 = "some_use"(%r1) : (vector<2xf32>) -> vector<2xf32>
      vector.transfer_write %u1, %memref0[%i, %i] : vector<2xf32>, memref<?x?xf32>
While %i is loop-invariant (which could hint that hoisting would be safe), the value of %r1 could actually change between the 1st and the 2nd iteration.

Your point about the value of %r1 changing is valid, however note that vector<2xf32> gets passed as an iter_arg of the function. There should be no visible effects of that transformation in the sequential case. However, we do know that there is a problem in the parallel case and it would generally be better to use the hoist tensor subsets transform instead (but there are other caveats).

Happy to jump on a call to dig deeper if useful.

At the moment, `hoistRedundantVectorTransfers` would hoist the `vector.transfer_read`/`vector.transfer_write` pair in this function: ```mlir func.func @no_hoisting_write_to_memref(%rhs: i32, %arg1: vector<1xi32>) { %c0_i32 = arith.constant 0 : i32 %c0 = arith.constant 0 : index %c1 = arith.constant 1 : index %c4 = arith.constant 4 : index %c20 = arith.constant 20 : index %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32> %cast = memref.cast %alloca : memref<1x1x2xi32> to memref<1x1x2xi32> %collapsed_1 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> scf.for %_ = %c0 to %c20 step %c4 { %collapsed_2 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> %lhs = vector.transfer_read %collapsed_1[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %acc = vector.transfer_read %collapsed_2[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %op = vector.outerproduct %lhs, %rhs, %acc {kind = #vector.kind<add>} : vector<1xi32>, i32 vector.transfer_write %op, %collapsed_1[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32> } return } ``` as follows: ```mlir func.func @no_hoisting_write_to_memref(%arg0: i32, %arg1: vector<1xi32>) { %c0_i32 = arith.constant 0 : i32 %c0 = arith.constant 0 : index %c4 = arith.constant 4 : index %c20 = arith.constant 20 : index %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32> %collapse_shape = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> %collapse_shape_0 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> %0 = vector.transfer_read %collapse_shape[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %1 = vector.transfer_read %collapse_shape_0[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %2 = scf.for %arg2 = %c0 to %c20 step %c4 iter_args(%arg3 = %0) -> (vector<1xi32>) { %3 = vector.outerproduct %arg3, %arg0, %1 {kind = #vector.kind<add>} : vector<1xi32>, i32 scf.yield %3 : vector<1xi32> } vector.transfer_write %2, %collapse_shape[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32> return } ``` This is not safe. While one argument for `vector.outerproduct` (`%rhs` from the original loop) is correctly being forwarded via `iter_args`, the other one (`%acc` from the original loop) is not. This patch disables hoisting in cases where the source of "candidate" `vector.transfer_read` aliases with some other `memref`. A more generic approach would be to make sure that all values are correctly forwarded via `iter_args`, but that would require involving alias analysis. [1] Based on iree-org/iree#14994.

banach-space · 2023-09-22T08:00:44Z

Your point about the value of %r1 changing is valid, however note that vector<2xf32> gets passed as an iter_arg of the function.

Thank you, I missed that originally and your pointer was incredibly helpful in pinning down the actual issue 🙏🏻 .

I've updated my repro to also include aliasing - that's where things start to break (also updated the summary with a full example). And hoist_vector_transfer_pairs is indeed correct - no aliasing there.

There should be no visible effects of that transformation in the sequential case. However, we do know that there is a problem in the parallel case and it would generally be better to use the hoist tensor subsets transform instead (but there are other caveats).

So I'm actually running things sequentially. Also, as this is coming from IREE, I have very limited control over whether the underlying IR operates on tensors or memrefs.

nicolasvasilache · 2023-09-28T10:04:48Z

mlir/lib/Dialect/Linalg/Transforms/Hoisting.cpp

+      // TODO: There might be other, similar cases missing here (i.e. other
+      // Memref Ops). 
+      auto source = transferRead.getSource();
+      if (source.getDefiningOp<memref::CollapseShapeOp>())


This is a bit too adhoc to my taste, can we use ViewLikeOpInterface to capture all the cases that may alias?

From what I see we should also update noAliasingUseInLoop to use ViewLikeOpInterface and avoid enumerating an incomplete list of ops.

Lastly, you also want to add a bit more documentation to hoistRedundantVectorTransfers point 3. to mention that one may also want to fold aliasing memref operations into vector.transfer ops (in addition to LICM) to improve the hoisting.

Makes sense, thanks a ton for the pointers!

Patch updated. Hopefully I haven't missed/misunderstood anything.

…hoisting Follow Nicolas' advice and use ViewLikeOpInterface, update docs

github-actions · 2023-09-29T08:40:28Z

✅ With the latest revision this PR passed the C/C++ code formatter.

nicolasvasilache

Looks good, thanks much!

Can you please fix the formatting before landing?
I see an error message from some presubmit.

…write} hoisting Fix formatting

…hoisting [mlir][vector] Prevent incorrect vector.transfer_{read|write} hoisting Refines how opportunities for hoisting vector.transfer_{read|write} pairs are identified. More specifically, rather than looking for specific MemRef ops that could lead to aliasing, this patch updates the hoisting logic to check whether the underlying Op implements `ViewLikeOpInterface`. Additional condition is added to prevent hoisting when one of the source operands implements `ViewLikeOpInterface`. This was motivated by the following example [1]: ```mlir func.func @no_hoisting_write_to_memref(%rhs: i32, %arg1: vector<1xi32>) { %c0_i32 = arith.constant 0 : i32 %c0 = arith.constant 0 : index %c1 = arith.constant 1 : index %c4 = arith.constant 4 : index %c20 = arith.constant 20 : index %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32> %cast = memref.cast %alloca : memref<1x1x2xi32> to memref<1x1x2xi32> %collapsed_1 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> scf.for %_ = %c0 to %c20 step %c4 { %collapsed_2 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> %lhs = vector.transfer_read %collapsed_1[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %acc = vector.transfer_read %collapsed_2[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %op = vector.outerproduct %lhs, %rhs, %acc {kind = #vector.kind<add>} : vector<1xi32>, i32 vector.transfer_write %op, %collapsed_1[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32> } return } ``` Originally, it would be rewritten as follows: ```mlir func.func @no_hoisting_write_to_memref(%arg0: i32, %arg1: vector<1xi32>) { %c0_i32 = arith.constant 0 : i32 %c0 = arith.constant 0 : index %c4 = arith.constant 4 : index %c20 = arith.constant 20 : index %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32> %collapse_shape = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> %collapse_shape_0 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32> %0 = vector.transfer_read %collapse_shape[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %1 = vector.transfer_read %collapse_shape_0[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32> %2 = scf.for %arg2 = %c0 to %c20 step %c4 iter_args(%arg3 = %0) -> (vector<1xi32>) { %3 = vector.outerproduct %arg3, %arg0, %1 {kind = #vector.kind<add>} : vector<1xi32>, i32 scf.yield %3 : vector<1xi32> } vector.transfer_write %2, %collapse_shape[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32> return } ``` This was not safe. While one argument for `vector.outerproduct` was correctly being forwarded via `iter_args` (`%rhs` from the original loop), the other one wasn't (`%acc` from the original loop). [1] Based on iree-org/iree#14994.

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

Recent changes (llvm#66930) disabled vector transfer ops hoisting with view-like intermediate ops. The recommended way is to fold subview ops into transfer op indices before invoking hoisting. That would mean now we see transfer op indices involving dynamic values, instead of static constant values before with subview ops. Therefore hoisting won't kick in anymore. This breaks downstream users. To fix it, this commit enables hoisting transfer ops with dynamic indices by using `ValueBoundsConstraintSet` to prove ranges are disjoint in `isDisjointTransferIndices`. Given that utility is used in many places including op folders, right now we introduce a flag to it and only set as true for "heavy" transforms in hoisting and load-store forwarding.

Recent changes (#66930) disabled vector transfer ops hoisting with view-like intermediate ops. The recommended way is to fold subview ops into transfer op indices before invoking hoisting. That would mean now we see transfer op indices involving dynamic values, instead of static constant values before with subview ops. Therefore hoisting won't kick in anymore. This breaks downstream users. To fix it, this commit enables hoisting transfer ops with dynamic indices by using `ValueBoundsConstraintSet` to prove ranges are disjoint in `isDisjointTransferIndices`. Given that utility is used in many places including op folders, right now we introduce a flag to it and only set as true for "heavy" transforms in hoisting and load-store forwarding.

…#68500) Recent changes (llvm#66930) disabled vector transfer ops hoisting with view-like intermediate ops. The recommended way is to fold subview ops into transfer op indices before invoking hoisting. That would mean now we see transfer op indices involving dynamic values, instead of static constant values before with subview ops. Therefore hoisting won't kick in anymore. This breaks downstream users. To fix it, this commit enables hoisting transfer ops with dynamic indices by using `ValueBoundsConstraintSet` to prove ranges are disjoint in `isDisjointTransferIndices`. Given that utility is used in many places including op folders, right now we introduce a flag to it and only set as true for "heavy" transforms in hoisting and load-store forwarding.

llvmbot added mlir:linalg mlir labels Sep 20, 2023

banach-space requested a review from matthias-springer September 20, 2023 17:19

banach-space force-pushed the andrzej/fix_hoisting branch from b5452fe to 38f0da3 Compare September 21, 2023 07:20

banach-space force-pushed the andrzej/fix_hoisting branch from 38f0da3 to 9aae59a Compare September 22, 2023 07:33

banach-space requested a review from nicolasvasilache September 22, 2023 07:33

banach-space marked this pull request as ready for review September 22, 2023 07:52

banach-space mentioned this pull request Sep 22, 2023

Incorrect vector.transfer_read + vector.transfer_write hoisting iree-org/iree#14994

Closed

nicolasvasilache reviewed Sep 28, 2023

View reviewed changes

fixup! [mlir][vector] Prevent incorrect vector.transfer_{read|write} …

7dbf2de

…hoisting Follow Nicolas' advice and use ViewLikeOpInterface, update docs

nicolasvasilache approved these changes Sep 29, 2023

View reviewed changes

banach-space added 2 commits September 29, 2023 09:10

fixup! fixup! [mlir][vector] Prevent incorrect vector.transfer_{read|…

57b50be

…write} hoisting Fix formatting

banach-space merged commit 94c0477 into llvm:main Sep 29, 2023

qedawkins mentioned this pull request Oct 1, 2023

[GPU] Vector transfer hoisting without view-like ops iree-org/iree#15083

Closed

stellaraccident added a commit to iree-org/llvm-project that referenced this pull request Oct 5, 2023

[LOCAL IREE REVERT FOR UNSOLVED ISSUE] Revert "[mlir][vector] Prevent…

6f1bc86

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

stellaraccident added a commit to iree-org/llvm-project that referenced this pull request Oct 5, 2023

[LOCAL IREE REVERT FOR UNSOLVED ISSUE] Revert "[mlir][vector] Prevent…

cf415e1

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

stellaraccident added a commit to iree-org/llvm-project that referenced this pull request Oct 5, 2023

[LOCAL IREE REVERT FOR UNSOLVED ISSUE] Revert "[mlir][vector] Prevent…

a27aef1

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

stellaraccident added a commit to iree-org/llvm-project that referenced this pull request Oct 5, 2023

[LOCAL IREE REVERT FOR UNSOLVED ISSUE] Revert "[mlir][vector] Prevent…

967827e

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

stellaraccident added a commit to iree-org/llvm-project that referenced this pull request Oct 5, 2023

[LOCAL IREE REVERT FOR UNSOLVED ISSUE] Revert "[mlir][vector] Prevent…

21f7825

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

stellaraccident added a commit to iree-org/llvm-project that referenced this pull request Oct 5, 2023

[LOCAL IREE REVERT FOR UNSOLVED ISSUE] Revert "[mlir][vector] Prevent…

0f53af9

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

stellaraccident added a commit to iree-org/llvm-project that referenced this pull request Oct 5, 2023

[LOCAL IREE REVERT FOR UNSOLVED ISSUE] Revert "[mlir][vector] Prevent…

c349c7f

… incorrect vector.transfer_{read|write} hoisting (llvm#66930)" This reverts commit 94c0477.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[mlir][vector] Prevent incorrect vector.transfer_{read|write} hoisting #66930

[mlir][vector] Prevent incorrect vector.transfer_{read|write} hoisting #66930

Uh oh!

banach-space commented Sep 20, 2023 •

edited

Loading

Uh oh!

llvmbot commented Sep 20, 2023 •

edited

Loading

Uh oh!

banach-space commented Sep 20, 2023

Uh oh!

nicolasvasilache commented Sep 21, 2023

Uh oh!

banach-space commented Sep 22, 2023

Uh oh!

nicolasvasilache Sep 28, 2023

Uh oh!

banach-space Sep 29, 2023

Uh oh!

github-actions bot commented Sep 29, 2023 •

edited

Loading

Uh oh!

nicolasvasilache left a comment

Uh oh!

Uh oh!

[mlir][vector] Prevent incorrect vector.transfer_{read|write} hoisting #66930

[mlir][vector] Prevent incorrect vector.transfer_{read|write} hoisting #66930

Uh oh!

Conversation

banach-space commented Sep 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Sep 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

banach-space commented Sep 20, 2023

Uh oh!

nicolasvasilache commented Sep 21, 2023

Uh oh!

banach-space commented Sep 22, 2023

Uh oh!

nicolasvasilache Sep 28, 2023

Choose a reason for hiding this comment

Uh oh!

banach-space Sep 29, 2023

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Sep 29, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nicolasvasilache left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

banach-space commented Sep 20, 2023 •

edited

Loading

llvmbot commented Sep 20, 2023 •

edited

Loading

github-actions bot commented Sep 29, 2023 •

edited

Loading