[Mlir-commits] [mlir] [mlir][ArmSME] Use liveness information in the tile allocator (PR #90448)
Benjamin Maxwell
llvmlistbot at llvm.org
Fri May 10 03:53:02 PDT 2024
================
@@ -23,12 +29,17 @@ func.func @constant_with_multiple_users(%a: vector<[4]xf32>, %b: vector<[4]xf32>
// -----
-// (No tile IDs -- the current tile allocator ignores this case)
+// CHECK-LIVE-RANGE-LABEL: @value_with_multiple_users
+// CHECK-LIVE-RANGE: ========== Coalesced Live Ranges:
+// CHECK-LIVE-RANGE: ^bb0:
+// CHECK-LIVE-RANGE-NEXT: |S arm_sme.move_vector_to_tile_slice
+// CHECK-LIVE-RANGE-NEXT: || arm_sme.move_vector_to_tile_slice
+// CHECK-LIVE-RANGE-NEXT: |E test.some_use
+// CHECK-LIVE-RANGE-NEXT: E test.some_use
-// CHECK-BAD-LABEL: @value_with_multiple_users
-// CHECK-BAD-NOT: tile_id
+// expected-note at below {{tile operand is: <block argument> of type 'vector<[4]x[4]xf32>'}}
func.func @value_with_multiple_users(%tile: vector<[4]x[4]xf32>, %a: vector<[4]xf32>, %b: vector<[4]xf32>, %index: index) {
- // A future allocator should error here (as `%tile` would need to be copied).
+ // expected-error at below {{op tile operand allocated to different SME virtial tile (move required)}}
----------------
MacDue wrote:
Requiring a move is not the same as running out of tiles. Think about the values (and were they're live). The first operation will modify `%tile` , but the second operation also needs the original `%tile`. So to ensure the second operation gets the correct value of `%tile` you need to emit a move.
https://github.com/llvm/llvm-project/pull/90448
More information about the Mlir-commits
mailing list