2019-02-09 09:02:28 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
|
|
; RUN: llc -mtriple=amdgcn -mcpu=gfx700 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX7 %s
|
|
|
|
; RUN: llc -mtriple=amdgcn -mcpu=gfx803 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX8 %s
|
|
|
|
; RUN: llc -mtriple=amdgcn -mcpu=gfx900 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX9-NODL %s
|
|
|
|
; RUN: llc -mtriple=amdgcn -mcpu=gfx906 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX9-DL %s
|
2019-06-21 00:29:40 +08:00
|
|
|
; RUN: llc -mtriple=amdgcn -mcpu=gfx1011 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX10-DL %s
|
|
|
|
; RUN: llc -mtriple=amdgcn -mcpu=gfx1012 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX10-DL %s
|
2019-02-09 09:02:28 +08:00
|
|
|
|
|
|
|
define amdgpu_kernel void @idot4_acc32(<4 x i8> addrspace(1)* %src1,
|
|
|
|
; GFX7-LABEL: idot4_acc32:
|
|
|
|
; GFX7: ; %bb.0: ; %entry
|
|
|
|
; GFX7-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x9
|
|
|
|
; GFX7-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0xd
|
|
|
|
; GFX7-NEXT: s_mov_b32 s3, 0xf000
|
|
|
|
; GFX7-NEXT: s_mov_b32 s2, -1
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX7-NEXT: s_load_dword s4, s[4:5], 0x0
|
|
|
|
; GFX7-NEXT: s_load_dword s5, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s12, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s6, s4
|
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s7, s5
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s9, s5, 0x80008
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v0, s7
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s12
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_bfe_i32 s11, s5, 0x80010
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s6, v0, v1
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s8, s4, 0x80008
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s9
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s10, s4, 0x80010
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s8, v1, v0
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s11
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_ashr_i32 s5, s5, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s10, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_ashr_i32 s4, s4, 24
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s5
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s4, v1, v0
|
|
|
|
; GFX7-NEXT: buffer_store_dword v0, off, s[0:3], 0
|
|
|
|
; GFX7-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX8-LABEL: idot4_acc32:
|
|
|
|
; GFX8: ; %bb.0: ; %entry
|
|
|
|
; GFX8-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX8-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX8-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX8-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_load_dword s10, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s4, s2
|
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s5, s3
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s7, s3, 0x80008
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s5
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s10
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s9, s3, 0x80010
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v0, s4, v0, v1
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s6, s2, 0x80008
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s7
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s8, s2, 0x80010
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v0, s6, v1, v0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s9
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_ashr_i32 s3, s3, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v0, s8, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_ashr_i32 s2, s2, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s2, v1, v0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: flat_store_dword v[0:1], v2
|
|
|
|
; GFX8-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-NODL-LABEL: idot4_acc32:
|
|
|
|
; GFX9-NODL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_load_dword s10, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s4, s2
|
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s5, s3
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s7, s3, 0x80008
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s5
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s10
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s9, s3, 0x80010
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v0, s4, v0, v1
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s6, s2, 0x80008
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s7
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s8, s2, 0x80010
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v0, s6, v1, v0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s9
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s3, s3, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v0, s8, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s2, s2, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s2, v1, v0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX9-NODL-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-DL-LABEL: idot4_acc32:
|
|
|
|
; GFX9-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: s_load_dword s2, s[6:7], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s3, s[0:1], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s4, s[4:5], 0x0
|
[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
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s2
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX9-DL-NEXT: v_dot4_i32_i8 v2, s4, v0, v1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX9-DL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX9-DL-NEXT: s_endpgm
|
2019-06-21 00:29:40 +08:00
|
|
|
;
|
|
|
|
; GFX10-DL-LABEL: idot4_acc32:
|
|
|
|
; GFX10-DL: ; %bb.0: ; %entry
|
2020-05-01 23:43:12 +08:00
|
|
|
; GFX10-DL-NEXT: s_clause 0x1
|
[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
|
|
|
; GFX10-DL-NEXT: s_load_dwordx2 s[4:5], s[0:1], 0x34
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx4 s[0:3], s[0:1], 0x24
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: ; implicit-def: $vcc_hi
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX10-DL-NEXT: s_load_dword s6, s[4:5], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s0, s[0:1], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s1, s[2:3], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s6
|
|
|
|
; GFX10-DL-NEXT: v_dot4_i32_i8 v2, s0, s1, v0
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s4
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v1, s5
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX10-DL-NEXT: s_endpgm
|
2019-02-09 09:02:28 +08:00
|
|
|
<4 x i8> addrspace(1)* %src2,
|
|
|
|
i32 addrspace(1)* nocapture %dst) {
|
|
|
|
entry:
|
|
|
|
%vec1 = load <4 x i8>, <4 x i8> addrspace(1)* %src1
|
|
|
|
%vec2 = load <4 x i8>, <4 x i8> addrspace(1)* %src2
|
|
|
|
|
|
|
|
%v1e0 = extractelement <4 x i8> %vec1, i64 0
|
|
|
|
%cv1e0 = sext i8 %v1e0 to i32
|
|
|
|
%v2e0 = extractelement <4 x i8> %vec2, i64 0
|
|
|
|
%cv2e0 = sext i8 %v2e0 to i32
|
|
|
|
%mul1 = mul nuw nsw i32 %cv1e0, %cv2e0
|
|
|
|
|
|
|
|
%v1e1 = extractelement <4 x i8> %vec1, i64 1
|
|
|
|
%cv1e1 = sext i8 %v1e1 to i32
|
|
|
|
%v2e1 = extractelement <4 x i8> %vec2, i64 1
|
|
|
|
%cv2e1 = sext i8 %v2e1 to i32
|
|
|
|
%mul2 = mul nuw nsw i32 %cv1e1, %cv2e1
|
|
|
|
|
|
|
|
%v1e2 = extractelement <4 x i8> %vec1, i64 2
|
|
|
|
%cv1e2 = sext i8 %v1e2 to i32
|
|
|
|
%v2e2 = extractelement <4 x i8> %vec2, i64 2
|
|
|
|
%cv2e2 = sext i8 %v2e2 to i32
|
|
|
|
%mul3 = mul nuw nsw i32 %cv1e2, %cv2e2
|
|
|
|
|
|
|
|
%v1e3 = extractelement <4 x i8> %vec1, i64 3
|
|
|
|
%cv1e3 = sext i8 %v1e3 to i32
|
|
|
|
%v2e3 = extractelement <4 x i8> %vec2, i64 3
|
|
|
|
%cv2e3 = sext i8 %v2e3 to i32
|
|
|
|
%mul4 = mul nuw nsw i32 %cv1e3, %cv2e3
|
|
|
|
|
|
|
|
%acc = load i32, i32 addrspace(1)* %dst, align 4
|
|
|
|
%add1 = add i32 %mul1, %acc
|
|
|
|
%add2 = add i32 %add1, %mul2
|
|
|
|
%add3 = add i32 %add2, %mul3
|
|
|
|
%add4 = add i32 %add3, %mul4
|
|
|
|
store i32 %add4, i32 addrspace(1)* %dst, align 4
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
; TODO: Currently, vector elements{0 and 3} get zero_extended from i16 to i32 which should
|
|
|
|
; be sign_extended directly to i32; prevents the pattern recognizer to recognize this pattern.
|
|
|
|
define amdgpu_kernel void @idot4_acc16(<4 x i8> addrspace(1)* %src1,
|
|
|
|
; GFX7-LABEL: idot4_acc16:
|
|
|
|
; GFX7: ; %bb.0: ; %entry
|
|
|
|
; GFX7-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x9
|
|
|
|
; GFX7-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0xd
|
|
|
|
; GFX7-NEXT: s_mov_b32 s3, 0xf000
|
|
|
|
; GFX7-NEXT: s_mov_b32 s2, -1
|
|
|
|
; GFX7-NEXT: s_mov_b32 s8, 0xffff
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX7-NEXT: buffer_load_ushort v0, off, s[0:3], 0
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s4, s[4:5], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s5, s[6:7], 0x0
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s6, s4
|
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s7, s5
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s10, s5, 0x80008
|
|
|
|
; GFX7-NEXT: s_and_b32 s7, s7, s8
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s12, s5, 0x80010
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: s_bfe_i32 s9, s4, 0x80008
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_and_b32 s10, s10, s8
|
|
|
|
; GFX7-NEXT: s_and_b32 s6, s6, s8
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s7
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s11, s4, 0x80010
|
|
|
|
; GFX7-NEXT: s_ashr_i32 s5, s5, 24
|
|
|
|
; GFX7-NEXT: s_and_b32 s12, s12, s8
|
|
|
|
; GFX7-NEXT: s_and_b32 s9, s9, s8
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v2, s10
|
|
|
|
; GFX7-NEXT: s_ashr_i32 s4, s4, 24
|
|
|
|
; GFX7-NEXT: s_and_b32 s11, s11, s8
|
|
|
|
; GFX7-NEXT: s_and_b32 s5, s5, s8
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v3, s12
|
|
|
|
; GFX7-NEXT: s_and_b32 s4, s4, s8
|
|
|
|
; GFX7-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s6, v1, v0
|
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s9, v2, v0
|
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s11, v3, v0
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s5
|
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s4, v1, v0
|
|
|
|
; GFX7-NEXT: buffer_store_short v0, off, s[0:3], 0
|
|
|
|
; GFX7-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX8-LABEL: idot4_acc16:
|
|
|
|
; GFX8: ; %bb.0: ; %entry
|
|
|
|
; GFX8-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX8-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_load_dword s2, s[6:7], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX8-NEXT: flat_load_ushort v2, v[0:1]
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_load_dword s0, s[4:5], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s3, s2
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s5, s2, 0x80008
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v3, s3
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s7, s2, 0x80010
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s1, s0
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s4, s0, 0x80008
|
[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
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v4, s5
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s6, s0, 0x80010
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX8-NEXT: s_ashr_i32 s2, s2, 24
|
[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
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v5, s7
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_ashr_i32 s0, s0, 24
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt vmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s1, v3, v2
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s4, v4, v2
|
[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
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s6, v5, v2
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v3, s2
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s0, v3, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: flat_store_short v[0:1], v2
|
|
|
|
; GFX8-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-NODL-LABEL: idot4_acc16:
|
|
|
|
; GFX9-NODL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_load_dword s2, s[6:7], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX9-NODL-NEXT: global_load_ushort v2, v[0:1], off
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_load_dword s0, s[4:5], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s3, s2
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s5, s2, 0x80008
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v3, s3
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s7, s2, 0x80010
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s1, s0
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s4, s0, 0x80008
|
[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
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v4, s5
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s6, s0, 0x80010
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s2, s2, 24
|
[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
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v5, s7
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s0, s0, 24
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_waitcnt vmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s1, v3, v2
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s4, v4, v2
|
[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
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s6, v5, v2
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v3, s2
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s0, v3, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: global_store_short v[0:1], v2, off
|
|
|
|
; GFX9-NODL-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-DL-LABEL: idot4_acc16:
|
|
|
|
; GFX9-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX9-DL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s3, s[6:7], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX9-DL-NEXT: global_load_ushort v2, v[0:1], off
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v3, s3
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_waitcnt vmcnt(0)
|
[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
|
|
|
; GFX9-DL-NEXT: v_dot4_i32_i8 v2, s2, v3, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: global_store_short v[0:1], v2, off
|
|
|
|
; GFX9-DL-NEXT: s_endpgm
|
2019-06-21 00:29:40 +08:00
|
|
|
;
|
|
|
|
; GFX10-DL-LABEL: idot4_acc16:
|
|
|
|
; GFX10-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx2 s[2:3], s[0:1], 0x34
|
|
|
|
; GFX10-DL-NEXT: ; implicit-def: $vcc_hi
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s2
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx4 s[0:3], s[0:1], 0x24
|
|
|
|
; GFX10-DL-NEXT: global_load_ushort v2, v[0:1], off
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s0, s[0:1], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s1, s[2:3], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt vmcnt(0) lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: v_dot4_i32_i8 v2, s0, s1, v2
|
|
|
|
; GFX10-DL-NEXT: global_store_short v[0:1], v2, off
|
|
|
|
; GFX10-DL-NEXT: s_endpgm
|
2019-02-09 09:02:28 +08:00
|
|
|
<4 x i8> addrspace(1)* %src2,
|
|
|
|
i16 addrspace(1)* nocapture %dst) {
|
|
|
|
entry:
|
|
|
|
%vec1 = load <4 x i8>, <4 x i8> addrspace(1)* %src1
|
|
|
|
%vec2 = load <4 x i8>, <4 x i8> addrspace(1)* %src2
|
|
|
|
|
|
|
|
%v1e0 = extractelement <4 x i8> %vec1, i64 0
|
|
|
|
%cv1e0 = sext i8 %v1e0 to i16
|
|
|
|
%v2e0 = extractelement <4 x i8> %vec2, i64 0
|
|
|
|
%cv2e0 = sext i8 %v2e0 to i16
|
|
|
|
%mul1 = mul nsw i16 %cv1e0, %cv2e0
|
|
|
|
|
|
|
|
%v1e1 = extractelement <4 x i8> %vec1, i64 1
|
|
|
|
%cv1e1 = sext i8 %v1e1 to i16
|
|
|
|
%v2e1 = extractelement <4 x i8> %vec2, i64 1
|
|
|
|
%cv2e1 = sext i8 %v2e1 to i16
|
|
|
|
%mul2 = mul nsw i16 %cv1e1, %cv2e1
|
|
|
|
|
|
|
|
%v1e2 = extractelement <4 x i8> %vec1, i64 2
|
|
|
|
%cv1e2 = sext i8 %v1e2 to i16
|
|
|
|
%v2e2 = extractelement <4 x i8> %vec2, i64 2
|
|
|
|
%cv2e2 = sext i8 %v2e2 to i16
|
|
|
|
%mul3 = mul nsw i16 %cv1e2, %cv2e2
|
|
|
|
|
|
|
|
%v1e3 = extractelement <4 x i8> %vec1, i64 3
|
|
|
|
%cv1e3 = sext i8 %v1e3 to i16
|
|
|
|
%v2e3 = extractelement <4 x i8> %vec2, i64 3
|
|
|
|
%cv2e3 = sext i8 %v2e3 to i16
|
|
|
|
%mul4 = mul nsw i16 %cv1e3, %cv2e3
|
|
|
|
|
|
|
|
%acc = load i16, i16 addrspace(1)* %dst, align 2
|
|
|
|
%add1 = add i16 %mul1, %acc
|
|
|
|
%add2 = add i16 %add1, %mul2
|
|
|
|
%add3 = add i16 %add2, %mul3
|
|
|
|
%add4 = add i16 %add3, %mul4
|
|
|
|
store i16 %add4, i16 addrspace(1)* %dst, align 2
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
define amdgpu_kernel void @idot4_acc8(<4 x i8> addrspace(1)* %src1,
|
|
|
|
; GFX7-LABEL: idot4_acc8:
|
|
|
|
; GFX7: ; %bb.0: ; %entry
|
|
|
|
; GFX7-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x9
|
|
|
|
; GFX7-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0xd
|
|
|
|
; GFX7-NEXT: s_mov_b32 s3, 0xf000
|
|
|
|
; GFX7-NEXT: s_mov_b32 s2, -1
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s6, s[6:7], 0x0
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: buffer_load_ubyte v0, off, s[0:3], 0
|
|
|
|
; GFX7-NEXT: s_load_dword s4, s[4:5], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_movk_i32 s5, 0xff
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_and_b32 s7, s6, s5
|
|
|
|
; GFX7-NEXT: s_bfe_u32 s8, s6, 0x80008
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: s_and_b32 s5, s4, s5
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s7
|
|
|
|
; GFX7-NEXT: s_bfe_u32 s10, s6, 0x80010
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: s_bfe_u32 s9, s4, 0x80008
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v2, s8
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: s_bfe_u32 s11, s4, 0x80010
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_lshr_b32 s6, s6, 24
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v3, s10
|
|
|
|
; GFX7-NEXT: s_lshr_b32 s4, s4, 24
|
|
|
|
; GFX7-NEXT: s_waitcnt vmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s5, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s9, v2, v0
|
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s11, v3, v0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s6
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: v_mad_u32_u24 v0, s4, v1, v0
|
|
|
|
; GFX7-NEXT: buffer_store_byte v0, off, s[0:3], 0
|
|
|
|
; GFX7-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX8-LABEL: idot4_acc8:
|
|
|
|
; GFX8: ; %bb.0: ; %entry
|
|
|
|
; GFX8-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX8-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_load_dword s2, s[4:5], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX8-NEXT: flat_load_ubyte v2, v[0:1]
|
|
|
|
; GFX8-NEXT: s_load_dword s1, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_movk_i32 s0, 0xff
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_bfe_u32 s5, s2, 0x80008
|
|
|
|
; GFX8-NEXT: s_bfe_u32 s7, s2, 0x80010
|
|
|
|
; GFX8-NEXT: s_and_b32 s3, s1, s0
|
|
|
|
; GFX8-NEXT: s_and_b32 s0, s2, s0
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX8-NEXT: s_bfe_u32 s4, s1, 0x80008
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v3, s3
|
|
|
|
; GFX8-NEXT: s_bfe_u32 s6, s1, 0x80010
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v4, s4
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_lshr_b32 s1, s1, 24
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v5, s6
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_lshr_b32 s2, s2, 24
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt vmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mad_u32_u24 v2, s0, v3, v2
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX8-NEXT: v_mad_u32_u24 v2, s5, v4, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: v_mad_u32_u24 v2, s7, v5, v2
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v3, s1
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mad_u32_u24 v2, s2, v3, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: flat_store_byte v[0:1], v2
|
|
|
|
; GFX8-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-NODL-LABEL: idot4_acc8:
|
|
|
|
; GFX9-NODL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_load_dword s2, s[4:5], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX9-NODL-NEXT: global_load_ubyte v2, v[0:1], off
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s1, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_movk_i32 s0, 0xff
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_bfe_u32 s5, s2, 0x80008
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_u32 s7, s2, 0x80010
|
|
|
|
; GFX9-NODL-NEXT: s_and_b32 s3, s1, s0
|
|
|
|
; GFX9-NODL-NEXT: s_and_b32 s0, s2, s0
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX9-NODL-NEXT: s_bfe_u32 s4, s1, 0x80008
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v3, s3
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_u32 s6, s1, 0x80010
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v4, s4
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_lshr_b32 s1, s1, 24
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v5, s6
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_lshr_b32 s2, s2, 24
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_waitcnt vmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_u32_u24 v2, s0, v3, v2
|
[DAGCombine] Prune unnused nodes.
Summary:
Nodes that have no uses are eventually pruned when they are selected
from the worklist. Record nodes newly added to the worklist or DAG and
perform pruning after every combine attempt.
Reviewers: efriedma, RKSimon, craig.topper, spatel, jyknight
Reviewed By: jyknight
Subscribers: jdoerfert, jyknight, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58070
llvm-svn: 357283
2019-03-30 01:35:56 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_u32_u24 v2, s5, v4, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_u32_u24 v2, s7, v5, v2
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v3, s1
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_u32_u24 v2, s2, v3, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: global_store_byte v[0:1], v2, off
|
|
|
|
; GFX9-NODL-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-DL-LABEL: idot4_acc8:
|
|
|
|
; GFX9-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX9-DL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s3, s[6:7], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX9-DL-NEXT: global_load_ubyte v2, v[0:1], off
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v3, s3
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_waitcnt vmcnt(0)
|
[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
|
|
|
; GFX9-DL-NEXT: v_dot4_u32_u8 v2, s2, v3, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: global_store_byte v[0:1], v2, off
|
|
|
|
; GFX9-DL-NEXT: s_endpgm
|
2019-06-21 00:29:40 +08:00
|
|
|
;
|
|
|
|
; GFX10-DL-LABEL: idot4_acc8:
|
|
|
|
; GFX10-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx2 s[2:3], s[0:1], 0x34
|
|
|
|
; GFX10-DL-NEXT: ; implicit-def: $vcc_hi
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s2
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx4 s[0:3], s[0:1], 0x24
|
|
|
|
; GFX10-DL-NEXT: global_load_ubyte v2, v[0:1], off
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s0, s[0:1], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s1, s[2:3], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt vmcnt(0) lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: v_dot4_u32_u8 v2, s0, s1, v2
|
|
|
|
; GFX10-DL-NEXT: global_store_byte v[0:1], v2, off
|
|
|
|
; GFX10-DL-NEXT: s_endpgm
|
2019-02-09 09:02:28 +08:00
|
|
|
<4 x i8> addrspace(1)* %src2,
|
|
|
|
i8 addrspace(1)* nocapture %dst) {
|
|
|
|
entry:
|
|
|
|
%vec1 = load <4 x i8>, <4 x i8> addrspace(1)* %src1
|
|
|
|
%vec2 = load <4 x i8>, <4 x i8> addrspace(1)* %src2
|
|
|
|
|
|
|
|
%v1e0 = extractelement <4 x i8> %vec1, i64 0
|
|
|
|
%v2e0 = extractelement <4 x i8> %vec2, i64 0
|
|
|
|
%mul1 = mul i8 %v1e0, %v2e0
|
|
|
|
|
|
|
|
%v1e1 = extractelement <4 x i8> %vec1, i64 1
|
|
|
|
%v2e1 = extractelement <4 x i8> %vec2, i64 1
|
|
|
|
%mul2 = mul i8 %v1e1, %v2e1
|
|
|
|
|
|
|
|
%v1e2 = extractelement <4 x i8> %vec1, i64 2
|
|
|
|
%v2e2 = extractelement <4 x i8> %vec2, i64 2
|
|
|
|
%mul3 = mul i8 %v1e2, %v2e2
|
|
|
|
|
|
|
|
%v1e3 = extractelement <4 x i8> %vec1, i64 3
|
|
|
|
%v2e3 = extractelement <4 x i8> %vec2, i64 3
|
|
|
|
%mul4 = mul i8 %v1e3, %v2e3
|
|
|
|
|
|
|
|
%acc = load i8, i8 addrspace(1)* %dst, align 2
|
|
|
|
%add1 = add i8 %mul1, %acc
|
|
|
|
%add2 = add i8 %add1, %mul2
|
|
|
|
%add3 = add i8 %add2, %mul3
|
|
|
|
%add4 = add nsw i8 %add3, %mul4
|
|
|
|
store i8 %add4, i8 addrspace(1)* %dst, align 2
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
define amdgpu_kernel void @idot4_multiuse_mul1(<4 x i8> addrspace(1)* %src1,
|
|
|
|
; GFX7-LABEL: idot4_multiuse_mul1:
|
|
|
|
; GFX7: ; %bb.0: ; %entry
|
|
|
|
; GFX7-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x9
|
|
|
|
; GFX7-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0xd
|
|
|
|
; GFX7-NEXT: s_mov_b32 s3, 0xf000
|
|
|
|
; GFX7-NEXT: s_mov_b32 s2, -1
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX7-NEXT: s_load_dword s4, s[4:5], 0x0
|
|
|
|
; GFX7-NEXT: s_load_dword s5, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s12, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s6, s4
|
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s7, s5
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s9, s5, 0x80008
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v0, s7
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s12
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_bfe_i32 s8, s4, 0x80008
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v1, s6, v0, v1
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v2, s9
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s11, s5, 0x80010
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v1, s8, v2, v1
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s10, s4, 0x80010
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s6, v0, v1
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s11
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_ashr_i32 s5, s5, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s10, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_ashr_i32 s4, s4, 24
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s5
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s4, v1, v0
|
|
|
|
; GFX7-NEXT: buffer_store_dword v0, off, s[0:3], 0
|
|
|
|
; GFX7-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX8-LABEL: idot4_multiuse_mul1:
|
|
|
|
; GFX8: ; %bb.0: ; %entry
|
|
|
|
; GFX8-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX8-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX8-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX8-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_load_dword s10, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s4, s2
|
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s5, s3
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s7, s3, 0x80008
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s5
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s10
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s6, s2, 0x80008
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v1, s4, v0, v1
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v2, s7
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s9, s3, 0x80010
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v1, s6, v2, v1
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s8, s2, 0x80010
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v0, s4, v0, v1
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s9
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_ashr_i32 s3, s3, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v0, s8, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_ashr_i32 s2, s2, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s2, v1, v0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: flat_store_dword v[0:1], v2
|
|
|
|
; GFX8-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-NODL-LABEL: idot4_multiuse_mul1:
|
|
|
|
; GFX9-NODL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_load_dword s10, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s4, s2
|
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s5, s3
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s7, s3, 0x80008
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s5
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s10
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s6, s2, 0x80008
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v1, s4, v0, v1
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v2, s7
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s9, s3, 0x80010
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v1, s6, v2, v1
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s8, s2, 0x80010
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v0, s4, v0, v1
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s9
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s3, s3, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v0, s8, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s2, s2, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s2, v1, v0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX9-NODL-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-DL-LABEL: idot4_multiuse_mul1:
|
|
|
|
; GFX9-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: s_load_dword s10, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: s_sext_i32_i8 s4, s2
|
|
|
|
; GFX9-DL-NEXT: s_sext_i32_i8 s5, s3
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s7, s3, 0x80008
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s5
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s10
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s6, s2, 0x80008
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v1, s4, v0, v1
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v2, s7
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s9, s3, 0x80010
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v1, s6, v2, v1
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s8, s2, 0x80010
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v0, s4, v0, v1
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s9
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_ashr_i32 s3, s3, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v0, s8, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_ashr_i32 s2, s2, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v2, s2, v1, v0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX9-DL-NEXT: s_endpgm
|
2019-06-21 00:29:40 +08:00
|
|
|
;
|
|
|
|
; GFX10-DL-LABEL: idot4_multiuse_mul1:
|
|
|
|
; GFX10-DL: ; %bb.0: ; %entry
|
2020-05-01 23:43:12 +08:00
|
|
|
; GFX10-DL-NEXT: s_clause 0x1
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: s_load_dwordx2 s[4:5], s[0:1], 0x34
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx4 s[0:3], s[0:1], 0x24
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: ; implicit-def: $vcc_hi
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: s_load_dword s6, s[4:5], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s0, s[0:1], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s1, s[2:3], 0x0
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s6
|
|
|
|
; GFX10-DL-NEXT: s_sext_i32_i8 s2, s0
|
|
|
|
; GFX10-DL-NEXT: s_sext_i32_i8 s3, s1
|
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s6, s0, 0x80008
|
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s7, s1, 0x80008
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v0, s2, s3, v0
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v0, s6, s7, v0
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v0, s2, s3, v0
|
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s2, s0, 0x80010
|
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s3, s1, 0x80010
|
|
|
|
; GFX10-DL-NEXT: s_ashr_i32 s0, s0, 24
|
|
|
|
; GFX10-DL-NEXT: s_ashr_i32 s1, s1, 24
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v0, s2, s3, v0
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v2, s0, s1, v0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s4
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v1, s5
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX10-DL-NEXT: s_endpgm
|
2019-02-09 09:02:28 +08:00
|
|
|
<4 x i8> addrspace(1)* %src2,
|
|
|
|
i32 addrspace(1)* nocapture %dst) {
|
|
|
|
entry:
|
|
|
|
%vec1 = load <4 x i8>, <4 x i8> addrspace(1)* %src1
|
|
|
|
%vec2 = load <4 x i8>, <4 x i8> addrspace(1)* %src2
|
|
|
|
|
|
|
|
%v1e0 = extractelement <4 x i8> %vec1, i64 0
|
|
|
|
%cv1e0 = sext i8 %v1e0 to i32
|
|
|
|
%v2e0 = extractelement <4 x i8> %vec2, i64 0
|
|
|
|
%cv2e0 = sext i8 %v2e0 to i32
|
|
|
|
%mul1 = mul nuw nsw i32 %cv1e0, %cv2e0
|
|
|
|
|
|
|
|
%v1e1 = extractelement <4 x i8> %vec1, i64 1
|
|
|
|
%cv1e1 = sext i8 %v1e1 to i32
|
|
|
|
%v2e1 = extractelement <4 x i8> %vec2, i64 1
|
|
|
|
%cv2e1 = sext i8 %v2e1 to i32
|
|
|
|
%mul2 = mul nuw nsw i32 %cv1e1, %cv2e1
|
|
|
|
|
|
|
|
%v1e2 = extractelement <4 x i8> %vec1, i64 2
|
|
|
|
%cv1e2 = sext i8 %v1e2 to i32
|
|
|
|
%v2e2 = extractelement <4 x i8> %vec2, i64 2
|
|
|
|
%cv2e2 = sext i8 %v2e2 to i32
|
|
|
|
%mul3 = mul nuw nsw i32 %cv1e2, %cv2e2
|
|
|
|
|
|
|
|
%v1e3 = extractelement <4 x i8> %vec1, i64 3
|
|
|
|
%cv1e3 = sext i8 %v1e3 to i32
|
|
|
|
%v2e3 = extractelement <4 x i8> %vec2, i64 3
|
|
|
|
%cv2e3 = sext i8 %v2e3 to i32
|
|
|
|
%mul4 = mul nuw nsw i32 %cv1e3, %cv2e3
|
|
|
|
|
|
|
|
%acc = load i32, i32 addrspace(1)* %dst, align 4
|
|
|
|
%add = add i32 %mul1, %acc
|
|
|
|
%add1 = add i32 %mul2, %add
|
|
|
|
%add2 = add i32 %add1, %mul1
|
|
|
|
%add3 = add i32 %add2, %mul3
|
|
|
|
%add4 = add i32 %add3, %mul4
|
|
|
|
|
|
|
|
store i32 %add4, i32 addrspace(1)* %dst, align 4
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
; TODO: Support this pattern.
|
|
|
|
define amdgpu_kernel void @idot4_acc32_vecMul(<4 x i8> addrspace(1)* %src1,
|
|
|
|
; GFX7-LABEL: idot4_acc32_vecMul:
|
|
|
|
; GFX7: ; %bb.0: ; %entry
|
|
|
|
; GFX7-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x9
|
|
|
|
; GFX7-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0xd
|
|
|
|
; GFX7-NEXT: s_mov_b32 s3, 0xf000
|
|
|
|
; GFX7-NEXT: s_mov_b32 s2, -1
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX7-NEXT: s_load_dword s4, s[4:5], 0x0
|
|
|
|
; GFX7-NEXT: s_load_dword s5, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s12, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_ashr_i32 s6, s4, 24
|
|
|
|
; GFX7-NEXT: s_ashr_i32 s9, s5, 24
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s10, s5, 0x80010
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s11, s5, 0x80008
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s5, s5
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: s_bfe_i32 s7, s4, 0x80010
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s8, s4, 0x80008
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s4, s4
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v0, s5
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s12
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s4, v0, v1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s11
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s8, v1, v0
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s10
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s7, v1, v0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s9
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s6, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: buffer_store_dword v0, off, s[0:3], 0
|
|
|
|
; GFX7-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX8-LABEL: idot4_acc32_vecMul:
|
|
|
|
; GFX8: ; %bb.0: ; %entry
|
|
|
|
; GFX8-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX8-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX8-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX8-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_load_dword s8, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_lshrrev_b16_e64 v0, 8, s2
|
|
|
|
; GFX8-NEXT: v_lshrrev_b16_e64 v1, 8, s3
|
|
|
|
; GFX8-NEXT: s_ashr_i32 s6, s3, 24
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s7, s3, 0x80010
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s3, s3
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_ashr_i32 s4, s2, 24
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s5, s2, 0x80010
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s2, s2
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v2, s3
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v3, s8
|
|
|
|
; GFX8-NEXT: v_bfe_i32 v0, v0, 0, 8
|
|
|
|
; GFX8-NEXT: v_bfe_i32 v1, v1, 0, 8
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s2, v2, v3
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v0, v0, v1, v2
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s7
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v0, s5, v1, v0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s6
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s4, v1, v0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: flat_store_dword v[0:1], v2
|
|
|
|
; GFX8-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-NODL-LABEL: idot4_acc32_vecMul:
|
|
|
|
; GFX9-NODL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_load_dword s8, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_lshrrev_b16_e64 v0, 8, s2
|
|
|
|
; GFX9-NODL-NEXT: v_lshrrev_b16_e64 v1, 8, s3
|
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s6, s3, 24
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s7, s3, 0x80010
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s3, s3
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: s_ashr_i32 s4, s2, 24
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s5, s2, 0x80010
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: s_sext_i32_i8 s2, s2
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v2, s3
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v3, s8
|
|
|
|
; GFX9-NODL-NEXT: v_bfe_i32 v0, v0, 0, 8
|
|
|
|
; GFX9-NODL-NEXT: v_bfe_i32 v1, v1, 0, 8
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s2, v2, v3
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v0, v0, v1, v2
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s7
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v0, s5, v1, v0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s6
|
|
|
|
; GFX9-NODL-NEXT: v_mad_i32_i24 v2, s4, v1, v0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-NODL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX9-NODL-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-DL-LABEL: idot4_acc32_vecMul:
|
|
|
|
; GFX9-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s3, s[6:7], 0x0
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: s_load_dword s8, s[0:1], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: v_lshrrev_b16_e64 v0, 8, s2
|
|
|
|
; GFX9-DL-NEXT: v_lshrrev_b16_e64 v1, 8, s3
|
|
|
|
; GFX9-DL-NEXT: s_ashr_i32 s6, s3, 24
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s7, s3, 0x80010
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_sext_i32_i8 s3, s3
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: s_ashr_i32 s4, s2, 24
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s5, s2, 0x80010
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: s_sext_i32_i8 s2, s2
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v2, s3
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v3, s8
|
|
|
|
; GFX9-DL-NEXT: v_bfe_i32 v0, v0, 0, 8
|
|
|
|
; GFX9-DL-NEXT: v_bfe_i32 v1, v1, 0, 8
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v2, s2, v2, v3
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v0, v0, v1, v2
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s7
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v0, s5, v1, v0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s6
|
|
|
|
; GFX9-DL-NEXT: v_mad_i32_i24 v2, s4, v1, v0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s1
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX9-DL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX9-DL-NEXT: s_endpgm
|
2019-06-21 00:29:40 +08:00
|
|
|
;
|
|
|
|
; GFX10-DL-LABEL: idot4_acc32_vecMul:
|
|
|
|
; GFX10-DL: ; %bb.0: ; %entry
|
2020-05-01 23:43:12 +08:00
|
|
|
; GFX10-DL-NEXT: s_clause 0x1
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX10-DL-NEXT: ; implicit-def: $vcc_hi
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s3, s[6:7], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s4, s[0:1], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: v_lshrrev_b16_e64 v0, 8, s2
|
|
|
|
; GFX10-DL-NEXT: v_lshrrev_b16_e64 v1, 8, s3
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v2, s4
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: s_sext_i32_i8 s4, s2
|
|
|
|
; GFX10-DL-NEXT: s_sext_i32_i8 s5, s3
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: v_bfe_i32 v0, v0, 0, 8
|
|
|
|
; GFX10-DL-NEXT: v_bfe_i32 v1, v1, 0, 8
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v2, s4, s5, v2
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s4, s2, 0x80010
|
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s5, s3, 0x80010
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: s_ashr_i32 s2, s2, 24
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: s_ashr_i32 s3, s3, 24
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v0, v0, v1, v2
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v0, s4, s5, v0
|
|
|
|
; GFX10-DL-NEXT: v_mad_i32_i24 v2, s2, s3, v0
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v1, s1
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: global_store_dword v[0:1], v2, off
|
|
|
|
; GFX10-DL-NEXT: s_endpgm
|
2019-02-09 09:02:28 +08:00
|
|
|
<4 x i8> addrspace(1)* %src2,
|
|
|
|
i32 addrspace(1)* nocapture %dst) {
|
|
|
|
entry:
|
|
|
|
%vec1 = load <4 x i8>, <4 x i8> addrspace(1)* %src1
|
|
|
|
%vec2 = load <4 x i8>, <4 x i8> addrspace(1)* %src2
|
|
|
|
|
|
|
|
%cvec1 = sext <4 x i8> %vec1 to <4 x i32>
|
|
|
|
%cvec2 = sext <4 x i8> %vec2 to <4 x i32>
|
|
|
|
|
|
|
|
%mul = mul <4 x i32> %cvec1, %cvec2
|
|
|
|
%mul0 = extractelement <4 x i32> %mul, i64 0
|
|
|
|
%mul1 = extractelement <4 x i32> %mul, i64 1
|
|
|
|
%mul2 = extractelement <4 x i32> %mul, i64 2
|
|
|
|
%mul3 = extractelement <4 x i32> %mul, i64 3
|
|
|
|
|
|
|
|
%acc = load i32, i32 addrspace(1)* %dst, align 4
|
|
|
|
%add1 = add i32 %mul0, %acc
|
|
|
|
%add2 = add i32 %add1, %mul1
|
|
|
|
%add3 = add i32 %add2, %mul2
|
|
|
|
%add4 = add i32 %add3, %mul3
|
|
|
|
|
|
|
|
store i32 %add4, i32 addrspace(1)* %dst, align 4
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
define amdgpu_kernel void @idot4_acc16_vecMul(<4 x i8> addrspace(1)* %src1,
|
|
|
|
; GFX7-LABEL: idot4_acc16_vecMul:
|
|
|
|
; GFX7: ; %bb.0: ; %entry
|
|
|
|
; GFX7-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x9
|
|
|
|
; GFX7-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0xd
|
|
|
|
; GFX7-NEXT: s_mov_b32 s3, 0xf000
|
|
|
|
; GFX7-NEXT: s_mov_b32 s2, -1
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX7-NEXT: buffer_load_ushort v0, off, s[0:3], 0
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s4, s[4:5], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_load_dword s5, s[6:7], 0x0
|
|
|
|
; GFX7-NEXT: s_waitcnt lgkmcnt(0)
|
2019-07-23 20:39:08 +08:00
|
|
|
; GFX7-NEXT: s_ashr_i32 s6, s4, 24
|
|
|
|
; GFX7-NEXT: s_bfe_i32 s10, s5, 0x80010
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_bfe_i32 s11, s5, 0x80008
|
2019-07-23 20:39:08 +08:00
|
|
|
; GFX7-NEXT: s_ashr_i32 s9, s5, 24
|
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s5, s5
|
2020-01-14 06:54:17 +08:00
|
|
|
; GFX7-NEXT: s_bfe_i32 s7, s4, 0x80010
|
2019-07-23 20:39:08 +08:00
|
|
|
; GFX7-NEXT: s_bfe_i32 s8, s4, 0x80008
|
|
|
|
; GFX7-NEXT: s_sext_i32_i8 s4, s4
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s5
|
2019-07-23 20:39:08 +08:00
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v2, s11
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v3, s10
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: s_waitcnt vmcnt(0)
|
2019-07-23 20:39:08 +08:00
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s4, v1, v0
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s8, v2, v0
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s7, v3, v0
|
|
|
|
; GFX7-NEXT: v_mov_b32_e32 v1, s9
|
|
|
|
; GFX7-NEXT: v_mad_i32_i24 v0, s6, v1, v0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX7-NEXT: buffer_store_short v0, off, s[0:3], 0
|
|
|
|
; GFX7-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX8-LABEL: idot4_acc16_vecMul:
|
|
|
|
; GFX8: ; %bb.0: ; %entry
|
|
|
|
; GFX8-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX8-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX8-NEXT: flat_load_ushort v2, v[0:1]
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX8-NEXT: s_load_dword s0, s[4:5], 0x0
|
[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
|
|
|
; GFX8-NEXT: s_load_dword s1, s[6:7], 0x0
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX8-NEXT: v_lshrrev_b16_e64 v3, 8, s0
|
|
|
|
; GFX8-NEXT: v_lshrrev_b16_e64 v4, 8, s1
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s5, s1, 0x80010
|
|
|
|
; GFX8-NEXT: s_ashr_i32 s4, s1, 24
|
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s1, s1
|
|
|
|
; GFX8-NEXT: s_ashr_i32 s2, s0, 24
|
|
|
|
; GFX8-NEXT: s_bfe_i32 s3, s0, 0x80010
|
|
|
|
; GFX8-NEXT: s_sext_i32_i8 s0, s0
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v5, s1
|
2020-02-20 23:49:22 +08:00
|
|
|
; GFX8-NEXT: v_bfe_i32 v3, v3, 0, 8
|
[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
|
|
|
; GFX8-NEXT: v_bfe_i32 v4, v4, 0, 8
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v6, s5
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: s_waitcnt vmcnt(0)
|
[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
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s0, v5, v2
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, v3, v4, v2
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s3, v6, v2
|
|
|
|
; GFX8-NEXT: v_mov_b32_e32 v3, s4
|
|
|
|
; GFX8-NEXT: v_mad_i32_i24 v2, s2, v3, v2
|
2019-02-09 09:02:28 +08:00
|
|
|
; GFX8-NEXT: flat_store_short v[0:1], v2
|
|
|
|
; GFX8-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-NODL-LABEL: idot4_acc16_vecMul:
|
|
|
|
; GFX9-NODL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-NODL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v4, 0xffff
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-NODL-NEXT: s_load_dword s3, s[6:7], 0x0
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-NODL-NEXT: s_lshr_b32 s4, s2, 16
|
|
|
|
; GFX9-NODL-NEXT: s_lshr_b32 s5, s3, 16
|
|
|
|
; GFX9-NODL-NEXT: v_ashrrev_i16_e64 v3, 8, s5
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s5, s5, 0x80000
|
|
|
|
; GFX9-NODL-NEXT: v_ashrrev_i16_e64 v2, 8, s4
|
|
|
|
; GFX9-NODL-NEXT: v_and_b32_e32 v5, s5, v4
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s4, s4, 0x80000
|
|
|
|
; GFX9-NODL-NEXT: v_lshl_or_b32 v3, v3, 16, v5
|
|
|
|
; GFX9-NODL-NEXT: v_and_b32_e32 v5, s4, v4
|
|
|
|
; GFX9-NODL-NEXT: v_lshl_or_b32 v2, v2, 16, v5
|
|
|
|
; GFX9-NODL-NEXT: v_ashrrev_i16_e64 v1, 8, s3
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s3, s3, 0x80000
|
|
|
|
; GFX9-NODL-NEXT: v_ashrrev_i16_e64 v0, 8, s2
|
|
|
|
; GFX9-NODL-NEXT: v_pk_mul_lo_u16 v2, v2, v3
|
|
|
|
; GFX9-NODL-NEXT: v_and_b32_e32 v3, s3, v4
|
|
|
|
; GFX9-NODL-NEXT: s_bfe_i32 s2, s2, 0x80000
|
|
|
|
; GFX9-NODL-NEXT: v_lshl_or_b32 v1, v1, 16, v3
|
|
|
|
; GFX9-NODL-NEXT: v_and_b32_e32 v3, s2, v4
|
|
|
|
; GFX9-NODL-NEXT: v_lshl_or_b32 v0, v0, 16, v3
|
|
|
|
; GFX9-NODL-NEXT: v_pk_mul_lo_u16 v3, v0, v1
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-NODL-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX9-NODL-NEXT: global_load_ushort v4, v[0:1], off
|
|
|
|
; GFX9-NODL-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
; GFX9-NODL-NEXT: v_add_u32_e32 v4, v3, v4
|
|
|
|
; GFX9-NODL-NEXT: v_add_u32_sdwa v3, v4, v3 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:WORD_1
|
|
|
|
; GFX9-NODL-NEXT: v_add_u32_e32 v3, v3, v2
|
|
|
|
; GFX9-NODL-NEXT: v_add_u32_sdwa v2, v3, v2 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:WORD_1
|
|
|
|
; GFX9-NODL-NEXT: global_store_short v[0:1], v2, off
|
|
|
|
; GFX9-NODL-NEXT: s_endpgm
|
|
|
|
;
|
|
|
|
; GFX9-DL-LABEL: idot4_acc16_vecMul:
|
|
|
|
; GFX9-DL: ; %bb.0: ; %entry
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx4 s[4:7], s[0:1], 0x24
|
|
|
|
; GFX9-DL-NEXT: s_load_dwordx2 s[0:1], s[0:1], 0x34
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v4, 0xffff
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s2, s[4:5], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_load_dword s3, s[6:7], 0x0
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX9-DL-NEXT: s_lshr_b32 s4, s2, 16
|
|
|
|
; GFX9-DL-NEXT: s_lshr_b32 s5, s3, 16
|
|
|
|
; GFX9-DL-NEXT: v_ashrrev_i16_e64 v3, 8, s5
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s5, s5, 0x80000
|
|
|
|
; GFX9-DL-NEXT: v_ashrrev_i16_e64 v2, 8, s4
|
|
|
|
; GFX9-DL-NEXT: v_and_b32_e32 v5, s5, v4
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s4, s4, 0x80000
|
|
|
|
; GFX9-DL-NEXT: v_lshl_or_b32 v3, v3, 16, v5
|
|
|
|
; GFX9-DL-NEXT: v_and_b32_e32 v5, s4, v4
|
|
|
|
; GFX9-DL-NEXT: v_lshl_or_b32 v2, v2, 16, v5
|
|
|
|
; GFX9-DL-NEXT: v_ashrrev_i16_e64 v1, 8, s3
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s3, s3, 0x80000
|
|
|
|
; GFX9-DL-NEXT: v_ashrrev_i16_e64 v0, 8, s2
|
|
|
|
; GFX9-DL-NEXT: v_pk_mul_lo_u16 v2, v2, v3
|
|
|
|
; GFX9-DL-NEXT: v_and_b32_e32 v3, s3, v4
|
|
|
|
; GFX9-DL-NEXT: s_bfe_i32 s2, s2, 0x80000
|
|
|
|
; GFX9-DL-NEXT: v_lshl_or_b32 v1, v1, 16, v3
|
|
|
|
; GFX9-DL-NEXT: v_and_b32_e32 v3, s2, v4
|
|
|
|
; GFX9-DL-NEXT: v_lshl_or_b32 v0, v0, 16, v3
|
|
|
|
; GFX9-DL-NEXT: v_pk_mul_lo_u16 v3, v0, v1
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v0, s0
|
|
|
|
; GFX9-DL-NEXT: v_mov_b32_e32 v1, s1
|
|
|
|
; GFX9-DL-NEXT: global_load_ushort v4, v[0:1], off
|
|
|
|
; GFX9-DL-NEXT: s_waitcnt vmcnt(0)
|
|
|
|
; GFX9-DL-NEXT: v_add_u32_e32 v4, v3, v4
|
|
|
|
; GFX9-DL-NEXT: v_add_u32_sdwa v3, v4, v3 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:WORD_1
|
|
|
|
; GFX9-DL-NEXT: v_add_u32_e32 v3, v3, v2
|
|
|
|
; GFX9-DL-NEXT: v_add_u32_sdwa v2, v3, v2 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:WORD_1
|
|
|
|
; GFX9-DL-NEXT: global_store_short v[0:1], v2, off
|
|
|
|
; GFX9-DL-NEXT: s_endpgm
|
2019-06-21 00:29:40 +08:00
|
|
|
;
|
|
|
|
; GFX10-DL-LABEL: idot4_acc16_vecMul:
|
|
|
|
; GFX10-DL: ; %bb.0: ; %entry
|
[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
|
|
|
; GFX10-DL-NEXT: s_load_dwordx2 s[2:3], s[0:1], 0x34
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v3, 0xffff
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: ; implicit-def: $vcc_hi
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[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
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v0, s2
|
|
|
|
; GFX10-DL-NEXT: v_mov_b32_e32 v1, s3
|
|
|
|
; GFX10-DL-NEXT: s_load_dwordx4 s[0:3], s[0:1], 0x24
|
|
|
|
; GFX10-DL-NEXT: global_load_ushort v2, v[0:1], off
|
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s0, s[0:1], 0x0
|
|
|
|
; GFX10-DL-NEXT: s_load_dword s1, s[2:3], 0x0
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: s_waitcnt lgkmcnt(0)
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: s_lshr_b32 s2, s0, 16
|
|
|
|
; GFX10-DL-NEXT: v_ashrrev_i16_e64 v4, 8, s0
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s0, s0, 0x80000
|
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s3, s1, 0x80000
|
|
|
|
; GFX10-DL-NEXT: v_and_b32_e32 v7, s0, v3
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: v_ashrrev_i16_e64 v5, 8, s1
|
[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
|
|
|
; GFX10-DL-NEXT: v_and_b32_e32 v6, s3, v3
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: s_lshr_b32 s0, s1, 16
|
|
|
|
; GFX10-DL-NEXT: v_ashrrev_i16_e64 v8, 8, s2
|
[AMDGPU] Fix typo in SIInstrInfo::memOpsHaveSameBasePtr
Summary:
The typo has been present since memOpsHaveSameBasePtr was introduced in
r313208.
It caused SIInstrInfo::shouldClusterMemOps to cluster more mem ops than
it was supposed to.
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71616
2019-12-18 00:09:02 +08:00
|
|
|
; GFX10-DL-NEXT: v_lshl_or_b32 v4, v4, 16, v7
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s1, s2, 0x80000
|
|
|
|
; GFX10-DL-NEXT: v_lshl_or_b32 v5, v5, 16, v6
|
|
|
|
; GFX10-DL-NEXT: s_bfe_i32 s2, s0, 0x80000
|
|
|
|
; GFX10-DL-NEXT: v_ashrrev_i16_e64 v6, 8, s0
|
|
|
|
; GFX10-DL-NEXT: v_and_b32_e32 v7, s2, v3
|
|
|
|
; GFX10-DL-NEXT: v_and_b32_e32 v3, s1, v3
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: v_pk_mul_lo_u16 v4, v4, v5
|
2020-03-11 19:33:30 +08:00
|
|
|
; GFX10-DL-NEXT: v_lshl_or_b32 v5, v6, 16, v7
|
|
|
|
; GFX10-DL-NEXT: v_lshl_or_b32 v3, v8, 16, v3
|
[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
|
|
|
; GFX10-DL-NEXT: v_pk_mul_lo_u16 v3, v3, v5
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: s_waitcnt vmcnt(0)
|
[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
|
|
|
; GFX10-DL-NEXT: v_add_nc_u32_e32 v2, v4, v2
|
|
|
|
; GFX10-DL-NEXT: v_add_nc_u32_sdwa v2, v2, v4 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:WORD_1
|
|
|
|
; GFX10-DL-NEXT: v_add_nc_u32_e32 v2, v2, v3
|
|
|
|
; GFX10-DL-NEXT: v_add_nc_u32_sdwa v2, v2, v3 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:WORD_1
|
2019-06-21 00:29:40 +08:00
|
|
|
; GFX10-DL-NEXT: global_store_short v[0:1], v2, off
|
|
|
|
; GFX10-DL-NEXT: s_endpgm
|
2019-02-09 09:02:28 +08:00
|
|
|
<4 x i8> addrspace(1)* %src2,
|
|
|
|
i16 addrspace(1)* nocapture %dst) {
|
|
|
|
entry:
|
|
|
|
%vec1 = load <4 x i8>, <4 x i8> addrspace(1)* %src1
|
|
|
|
%vec2 = load <4 x i8>, <4 x i8> addrspace(1)* %src2
|
|
|
|
|
|
|
|
%cvec1 = sext <4 x i8> %vec1 to <4 x i16>
|
|
|
|
%cvec2 = sext <4 x i8> %vec2 to <4 x i16>
|
|
|
|
|
|
|
|
%mul = mul <4 x i16> %cvec1, %cvec2
|
|
|
|
%mul0 = extractelement <4 x i16> %mul, i64 0
|
|
|
|
%mul1 = extractelement <4 x i16> %mul, i64 1
|
|
|
|
%mul2 = extractelement <4 x i16> %mul, i64 2
|
|
|
|
%mul3 = extractelement <4 x i16> %mul, i64 3
|
|
|
|
|
|
|
|
%acc = load i16, i16 addrspace(1)* %dst, align 4
|
|
|
|
%add1 = add i16 %mul0, %acc
|
|
|
|
%add2 = add i16 %add1, %mul1
|
|
|
|
%add3 = add i16 %add2, %mul2
|
|
|
|
%add4 = add i16 %add3, %mul3
|
|
|
|
|
|
|
|
store i16 %add4, i16 addrspace(1)* %dst, align 4
|
|
|
|
ret void
|
|
|
|
}
|