maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/AMDGPU/scheduler-handle-move-bundl...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

53 lines
2.3 KiB
Plaintext
Raw Normal View History

LiveIntervals: Fix handleMove asserting on BUNDLE The top-level BUNDLE instruction should behave as an ordinary instruction. It is supposed to have all relevant registers as implicit operands. Moving it should work as any other instruction. I believe the assert intended to avoid moving instructions inside bundles. llvm-svn: 366605
2019-07-20 03:32:00 +08:00
# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
# RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx1010 -run-pass=machine-scheduler -verify-machineinstrs -o - %s | FileCheck -check-prefix=GCN %s
# handleMove was called for the BUNDLE pseudo-instruction, but
# considered it to be an instruction in the bundle. Make sure it
# doesn't assert when the whole bundle is moved.
---
name: handleMove_bundle
tracksRegLiveness: true
machineFunctionInfo:
isEntryFunction: true
memoryBound: false
waveLimiter: false
body: |
bb.0:
liveins: $sgpr4_sgpr5
; GCN-LABEL: name: handleMove_bundle
; GCN: liveins: $sgpr4_sgpr5
; GCN: [[COPY:%[0-9]+]]:sgpr_64 = COPY $sgpr4_sgpr5
; GCN: [[S_LOAD_DWORD_IMM:%[0-9]+]]:sreg_32_xm0_xexec = S_LOAD_DWORD_IMM [[COPY]], 0, 0, 0 :: (dereferenceable invariant load 4, align 16, addrspace 4)
[AMDGPU] Remove dubious logic in bidirectional list scheduler Summary: pickNodeBidirectional tried to compare the best top candidate and the best bottom candidate by examining TopCand.Reason and BotCand.Reason. This is unsound because, after calling pickNodeFromQueue, Cand.Reason does not reflect the most important reason why Cand was chosen. Rather it reflects the most recent reason why it beat some other potential candidate, which could have been for some low priority tie breaker reason. I have seen this cause problems where TopCand is a good candidate, but because TopCand.Reason is ORDER (which is very low priority) it is repeatedly ignored in favour of a mediocre BotCand. This is not how bidirectional scheduling is supposed to work. To fix this I changed the code to always compare TopCand and BotCand directly, like the generic implementation of pickNodeBidirectional does. This removes some uncommented AMDGPU-specific logic; if this logic turns out to be important then perhaps it could be moved into an override of tryCandidate instead. Graphics shader benchmarking on gfx10 shows a lot more positive than negative effects from this change. Reviewers: arsenm, tstellar, rampitec, kzhuravl, vpykhtin, dstuttard, tpr, atrick, MatzeB Subscribers: jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68338
2019-10-07 22:33:59 +08:00
; GCN: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 1, implicit $exec
LiveIntervals: Fix handleMove asserting on BUNDLE The top-level BUNDLE instruction should behave as an ordinary instruction. It is supposed to have all relevant registers as implicit operands. Moving it should work as any other instruction. I believe the assert intended to avoid moving instructions inside bundles. llvm-svn: 366605
2019-07-20 03:32:00 +08:00
; GCN: [[V_MOV_B32_e32_1:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 0, implicit $exec
[AMDGPU] Remove dubious logic in bidirectional list scheduler Summary: pickNodeBidirectional tried to compare the best top candidate and the best bottom candidate by examining TopCand.Reason and BotCand.Reason. This is unsound because, after calling pickNodeFromQueue, Cand.Reason does not reflect the most important reason why Cand was chosen. Rather it reflects the most recent reason why it beat some other potential candidate, which could have been for some low priority tie breaker reason. I have seen this cause problems where TopCand is a good candidate, but because TopCand.Reason is ORDER (which is very low priority) it is repeatedly ignored in favour of a mediocre BotCand. This is not how bidirectional scheduling is supposed to work. To fix this I changed the code to always compare TopCand and BotCand directly, like the generic implementation of pickNodeBidirectional does. This removes some uncommented AMDGPU-specific logic; if this logic turns out to be important then perhaps it could be moved into an override of tryCandidate instead. Graphics shader benchmarking on gfx10 shows a lot more positive than negative effects from this change. Reviewers: arsenm, tstellar, rampitec, kzhuravl, vpykhtin, dstuttard, tpr, atrick, MatzeB Subscribers: jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68338
2019-10-07 22:33:59 +08:00
; GCN: $vcc_hi = IMPLICIT_DEF
[AMDGPU] Fix getInstrLatency() always returning 1 We do not have InstrItinerary so generic getInstLatency() was always defaulting to return 1 cycle. We need to use TargetSchedModel instead to compute an instruction's latency. Differential Revision: https://reviews.llvm.org/D72655
2020-01-14 06:30:21 +08:00
; GCN: [[V_MOV_B32_e32_2:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 2, implicit $exec
AMDGPU: Remove mayLoad/mayStore from some side effecting intrinsics These don't really modify any memory, and should not expect memory operands.
2020-05-28 12:11:26 +08:00
; GCN: DS_WRITE_B32_gfx9 [[V_MOV_B32_e32_1]], [[V_MOV_B32_e32_]], 0, 0, implicit $exec :: (store 4, addrspace 3)
LiveIntervals: Fix handleMove asserting on BUNDLE The top-level BUNDLE instruction should behave as an ordinary instruction. It is supposed to have all relevant registers as implicit operands. Moving it should work as any other instruction. I believe the assert intended to avoid moving instructions inside bundles. llvm-svn: 366605
2019-07-20 03:32:00 +08:00
; GCN: $vgpr0 = COPY [[S_LOAD_DWORD_IMM]]
[AMDGPU] More accurate gfx10 latencies Differential Revision: https://reviews.llvm.org/D81012
2020-03-11 19:33:30 +08:00
; GCN: $m0 = S_MOV_B32 0
LiveIntervals: Fix handleMove asserting on BUNDLE The top-level BUNDLE instruction should behave as an ordinary instruction. It is supposed to have all relevant registers as implicit operands. Moving it should work as any other instruction. I believe the assert intended to avoid moving instructions inside bundles. llvm-svn: 366605
2019-07-20 03:32:00 +08:00
; GCN: BUNDLE implicit $vgpr0, implicit $m0, implicit $exec {
[AMDGPU] Remove gds operand from ds_gws_* MachineInstrs The operand value was always 1 (except in some bad MIR tests) so it was redundant. Differential Revision: https://reviews.llvm.org/D90378
2020-10-29 18:20:54 +08:00
; GCN: DS_GWS_INIT $vgpr0, 11, implicit $m0, implicit $exec :: (store 4)
LiveIntervals: Fix handleMove asserting on BUNDLE The top-level BUNDLE instruction should behave as an ordinary instruction. It is supposed to have all relevant registers as implicit operands. Moving it should work as any other instruction. I believe the assert intended to avoid moving instructions inside bundles. llvm-svn: 366605
2019-07-20 03:32:00 +08:00
; GCN: S_WAITCNT 0
; GCN: }
; GCN: DS_WRITE_B32_gfx9 [[V_MOV_B32_e32_1]], [[V_MOV_B32_e32_2]], 0, 0, implicit $exec :: (store 4, addrspace 3)
; GCN: S_ENDPGM 0
$vcc_hi = IMPLICIT_DEF
%2:sgpr_64 = COPY $sgpr4_sgpr5
%5:sreg_32_xm0_xexec = S_LOAD_DWORD_IMM %2, 0, 0, 0 :: (dereferenceable invariant load 4, align 16, addrspace 4)
%6:vgpr_32 = V_MOV_B32_e32 1, implicit $exec
%7:vgpr_32 = V_MOV_B32_e32 0, implicit $exec
DS_WRITE_B32_gfx9 %7, %6, 0, 0, implicit $exec :: (store 4, addrspace 3)
$m0 = S_MOV_B32 0
$vgpr0 = COPY %5
BUNDLE implicit killed $vgpr0, implicit $m0, implicit $exec {
[AMDGPU] Remove gds operand from ds_gws_* MachineInstrs The operand value was always 1 (except in some bad MIR tests) so it was redundant. Differential Revision: https://reviews.llvm.org/D90378
2020-10-29 18:20:54 +08:00
DS_GWS_INIT $vgpr0, 11, implicit $m0, implicit $exec :: (store 4)
LiveIntervals: Fix handleMove asserting on BUNDLE The top-level BUNDLE instruction should behave as an ordinary instruction. It is supposed to have all relevant registers as implicit operands. Moving it should work as any other instruction. I believe the assert intended to avoid moving instructions inside bundles. llvm-svn: 366605
2019-07-20 03:32:00 +08:00
S_WAITCNT 0
}
%8:vgpr_32 = V_MOV_B32_e32 2, implicit $exec
DS_WRITE_B32_gfx9 %7, %8, 0, 0, implicit $exec :: (store 4, addrspace 3)
S_ENDPGM 0
...