Files
clang-p2996/llvm/test/CodeGen/AMDGPU/merge-load-store-physreg.mir
Jay Foad 359a792f9b [AMDGPU] SILoadStoreOptimizer: avoid unbounded register pressure increases
Previously when combining two loads this pass would sink the
first one down to the second one, putting the combined load
where the second one was. It would also sink any intervening
instructions which depended on the first load down to just
after the combined load.

For example, if we started with this sequence of
instructions (code flowing from left to right):

  X A B C D E F Y

After combining loads X and Y into XY we might end up with:

  A B C D E F XY

But if B D and F depended on X, we would get:

  A C E XY B D F

Now if the original code had some short disjoint live ranges
from A to B, C to D and E to F, in the transformed code
these live ranges will be long and overlapping. In this way
a single merge of two loads could cause an unbounded
increase in register pressure.

To fix this, change the way the way that loads are moved in
order to merge them so that:
- The second load is moved up to the first one. (But when
  merging stores, we still move the first store down to the
  second one.)
- Intervening instructions are never moved.
- Instead, if we find an intervening instruction that would
  need to be moved, give up on the merge. But this case
  should now be pretty rare because normal stores have no
  outputs, and normal loads only have address register
  inputs, but these will be identical for any pair of loads
  that we try to merge.

As well as fixing the unbounded register pressure increase
problem, moving loads up and stores down seems like it
should usually be a win for memory latency reasons.

Differential Revision: https://reviews.llvm.org/D119006
2022-02-21 10:51:14 +00:00

63 lines
1.8 KiB
YAML

# RUN: llc -march=amdgcn -verify-machineinstrs -run-pass si-load-store-opt -o - %s | FileCheck %s
# Check that SILoadStoreOptimizer honors physregs defs/uses between moved
# instructions.
#
# The following IR snippet would usually be optimized by the peephole optimizer.
# However, an equivalent situation can occur with buffer instructions as well.
# CHECK-LABEL: name: scc_def_and_use_no_dependency
# CHECK: DS_READ2_B32
# CHECK: S_ADD_U32
# CHECK: S_ADDC_U32
---
name: scc_def_and_use_no_dependency
machineFunctionInfo:
isEntryFunction: true
body: |
bb.0:
liveins: $vgpr0, $sgpr0
%1:vgpr_32 = COPY $vgpr0
%10:sgpr_32 = COPY $sgpr0
$m0 = S_MOV_B32 -1
%2:vgpr_32 = DS_READ_B32 %1, 0, 0, implicit $m0, implicit $exec :: (load (s32))
%11:sgpr_32 = S_ADD_U32 %10, 4, implicit-def $scc
%12:sgpr_32 = S_ADDC_U32 %10, 0, implicit-def dead $scc, implicit $scc
%3:vgpr_32 = DS_READ_B32 %1, 64, 0, implicit $m0, implicit $exec :: (load (s32))
S_ENDPGM 0
...
# CHECK-LABEL: name: scc_def_and_use_dependency
# CHECK: DS_READ2_B32
# CHECK: S_ADD_U32
# CHECK: S_ADDC_U32
---
name: scc_def_and_use_dependency
machineFunctionInfo:
isEntryFunction: true
body: |
bb.0:
liveins: $vgpr0, $sgpr0
%1:vgpr_32 = COPY $vgpr0
%10:sgpr_32 = COPY $sgpr0
$m0 = S_MOV_B32 -1
%2:vgpr_32 = DS_READ_B32 %1, 0, 0, implicit $m0, implicit $exec :: (load (s32))
%20:sgpr_32 = V_READFIRSTLANE_B32 %2, implicit $exec
%21:sgpr_32 = S_ADD_U32 %20, 4, implicit-def $scc
; The S_ADDC_U32 depends on the first DS_READ_B32 only via SCC
%11:sgpr_32 = S_ADDC_U32 %10, 0, implicit-def dead $scc, implicit $scc
%3:vgpr_32 = DS_READ_B32 %1, 64, 0, implicit $m0, implicit $exec :: (load (s32))
S_ENDPGM 0
...