1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-02-01 13:11:39 +01:00
Jay Foad 654464aac1 [SplitKit] Only copy live lanes
When splitting a live interval with subranges, only insert copies for
the lanes that are live at the point of the split. This avoids some
unnecessary copies and fixes a problem where copying dead lanes was
generating MIR that failed verification. The test case for this is
test/CodeGen/AMDGPU/splitkit-copy-live-lanes.mir.

Without this fix, some earlier live range splitting would create %430:

%430 [256r,848r:0)[848r,2584r:1)  0@256r 1@848r L0000000000000003 [848r,2584r:0)  0@848r L0000000000000030 [256r,2584r:0)  0@256r weight:1.480938e-03
...
256B     undef %430.sub2:vreg_128 = V_LSHRREV_B32_e32 16, %20.sub1:vreg_128, implicit $exec
...
848B     %430.sub0:vreg_128 = V_AND_B32_e32 %92:sreg_32, %20.sub1:vreg_128, implicit $exec
...
2584B    %431:vreg_128 = COPY %430:vreg_128

Then RAGreedy::tryLocalSplit would split %430 into %432 and %433 just
before 848B giving:

%432 [256r,844r:0)  0@256r L0000000000000030 [256r,844r:0)  0@256r weight:3.066802e-03
%433 [844r,848r:0)[848r,2584r:1)  0@844r 1@848r L0000000000000030 [844r,2584r:0)  0@844r L0000000000000003 [844r,844d:0)[848r,2584r:1)  0@844r 1@848r weight:2.831776e-03
...
256B     undef %432.sub2:vreg_128 = V_LSHRREV_B32_e32 16, %20.sub1:vreg_128, implicit $exec
...
844B     undef %433.sub0:vreg_128 = COPY %432.sub0:vreg_128 {
           internal %433.sub2:vreg_128 = COPY %432.sub2:vreg_128
848B     }
  %433.sub0:vreg_128 = V_AND_B32_e32 %92:sreg_32, %20.sub1:vreg_128, implicit $exec
...
2584B    %431:vreg_128 = COPY %433:vreg_128

Note that the copy from %432 to %433 at 844B is a curious
bundle-without-a-BUNDLE-instruction that SplitKit creates deliberately,
and it includes a copy of .sub0 which is not live at this point, and
that causes it to fail verification:

*** Bad machine code: No live subrange at use ***
- function:    zextload_global_v64i16_to_v64i64
- basic block: %bb.0  (0x7faed48) [0B;2848B)
- instruction: 844B    undef %433.sub0:vreg_128 = COPY %432.sub0:vreg_128
- operand 1:   %432.sub0:vreg_128
- interval:    %432 [256r,844r:0)  0@256r L0000000000000030 [256r,844r:0)  0@256r weight:3.066802e-03
- at:          844B

Using real bundles with a BUNDLE instruction might also fix this
problem, but the current fix is less invasive and also avoids some
unnecessary copies.

https://bugs.llvm.org/show_bug.cgi?id=47492

Differential Revision: https://reviews.llvm.org/D87757
2020-09-17 09:26:11 +01:00
..
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-06-25 10:38:23 +02:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-09-14 13:40:17 +01:00
2020-08-05 12:36:26 -07:00
2020-08-05 12:36:26 -07:00
2020-08-05 12:36:26 -07:00
2020-08-05 12:36:26 -07:00
2020-06-15 16:18:05 -07:00
2020-08-09 20:50:30 +02:00
2020-06-15 16:18:05 -07:00
2020-09-14 13:40:17 +01:00
2020-09-14 13:40:17 +01:00
2020-06-15 16:18:05 -07:00
2020-09-15 19:13:39 -07:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-06-25 10:38:23 +02:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-04-03 10:07:21 +01:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-06-15 16:18:05 -07:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-06-15 16:18:05 -07:00
2020-08-09 20:50:30 +02:00
2020-01-12 22:44:51 -05:00

+==============================================================================+
| How to organize the lit tests                                                |
+==============================================================================+

- If you write a test for matching a single DAG opcode or intrinsic, it should
  go in a file called {opcode_name,intrinsic_name}.ll (e.g. fadd.ll)

- If you write a test that matches several DAG opcodes and checks for a single
  ISA instruction, then that test should go in a file called {ISA_name}.ll (e.g.
  bfi_int.ll

- For all other tests, use your best judgement for organizing tests and naming
  the files.

+==============================================================================+
| Naming conventions                                                           |
+==============================================================================+

- Use dash '-' and not underscore '_' to separate words in file names, unless
  the file is named after a DAG opcode or ISA instruction that has an
  underscore '_' in its name.