maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-atomicrmw-fadd-...

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

117 lines
5.6 KiB
Plaintext
Raw Normal View History

AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
AMDGPU/GlobalISel: Fix making LDS FP atomics legal on SI/CI
2020-06-05 03:21:20 +08:00
# RUN: llc -march=amdgcn -mcpu=fiji -run-pass=instruction-select -verify-machineinstrs -global-isel-abort=0 -o - %s | FileCheck -check-prefix=GFX8 %s
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
# RUN: llc -march=amdgcn -mcpu=gfx900 -run-pass=instruction-select -verify-machineinstrs -global-isel-abort=0 -o - %s | FileCheck -check-prefix=GFX9 %s
AMDGPU/GlobalISel: Fix some broken run lines llvm-svn: 371992
2019-09-16 22:14:40 +08:00
# RUN: llc -march=amdgcn -mcpu=gfx1010 -run-pass=instruction-select -verify-machineinstrs -global-isel-abort=0 -o - %s | FileCheck -check-prefix=GFX9 %s
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
AMDGPU/GlobalISel: Fix test failure in release build The annoying behavior where the output is different due to the legality check struck again, plus the subtarget predicate wasn't really correctly set for DS FP atomics. Some of the FP min/max instructions seem to be in the gfx6/gfx7 manuals, but IIRC this might have been one of the cases where the manual got ahead of the actual hardware support, but I've left these as-is for now since the assembler tests seem to expect them.
2020-06-06 22:31:08 +08:00
# GFX6/7 selection should fail.
# RUN: llc -march=amdgcn -mcpu=tahiti -run-pass=instruction-select -verify-machineinstrs -global-isel-abort=0 -disable-gisel-legality-check -o - %s | FileCheck -check-prefix=GFX6 %s
# RUN: llc -march=amdgcn -mcpu=hawaii -run-pass=instruction-select -verify-machineinstrs -global-isel-abort=0 -disable-gisel-legality-check -o - %s | FileCheck -check-prefix=GFX6 %s
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
---
name: atomicrmw_fadd_s32_local
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0, $vgpr1
AMDGPU/GlobalISel: Fix making LDS FP atomics legal on SI/CI
2020-06-05 03:21:20 +08:00
; GFX8-LABEL: name: atomicrmw_fadd_s32_local
; GFX8: liveins: $vgpr0, $vgpr1
; GFX8: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GFX8: [[COPY1:%[0-9]+]]:vgpr_32 = COPY $vgpr1
; GFX8: $m0 = S_MOV_B32 -1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX8: [[DS_ADD_RTN_F32_:%[0-9]+]]:vgpr_32 = DS_ADD_RTN_F32 [[COPY]], [[COPY1]], 0, 0, implicit $m0, implicit $exec :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Fix making LDS FP atomics legal on SI/CI
2020-06-05 03:21:20 +08:00
; GFX8: $vgpr0 = COPY [[DS_ADD_RTN_F32_]]
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
; GFX9-LABEL: name: atomicrmw_fadd_s32_local
; GFX9: liveins: $vgpr0, $vgpr1
; GFX9: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GFX9: [[COPY1:%[0-9]+]]:vgpr_32 = COPY $vgpr1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX9: [[DS_ADD_RTN_F32_gfx9_:%[0-9]+]]:vgpr_32 = DS_ADD_RTN_F32_gfx9 [[COPY]], [[COPY1]], 0, 0, implicit $exec :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
; GFX9: $vgpr0 = COPY [[DS_ADD_RTN_F32_gfx9_]]
AMDGPU/GlobalISel: Fix test failure in release build The annoying behavior where the output is different due to the legality check struck again, plus the subtarget predicate wasn't really correctly set for DS FP atomics. Some of the FP min/max instructions seem to be in the gfx6/gfx7 manuals, but IIRC this might have been one of the cases where the manual got ahead of the actual hardware support, but I've left these as-is for now since the assembler tests seem to expect them.
2020-06-06 22:31:08 +08:00
; GFX6-LABEL: name: atomicrmw_fadd_s32_local
; GFX6: liveins: $vgpr0, $vgpr1
; GFX6: [[COPY:%[0-9]+]]:vgpr(p3) = COPY $vgpr0
; GFX6: [[COPY1:%[0-9]+]]:vgpr(s32) = COPY $vgpr1
; GFX6: $m0 = S_MOV_B32 -1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX6: [[ATOMICRMW_FADD:%[0-9]+]]:vgpr_32(s32) = G_ATOMICRMW_FADD [[COPY]](p3), [[COPY1]] :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Fix test failure in release build The annoying behavior where the output is different due to the legality check struck again, plus the subtarget predicate wasn't really correctly set for DS FP atomics. Some of the FP min/max instructions seem to be in the gfx6/gfx7 manuals, but IIRC this might have been one of the cases where the manual got ahead of the actual hardware support, but I've left these as-is for now since the assembler tests seem to expect them.
2020-06-06 22:31:08 +08:00
; GFX6: $vgpr0 = COPY [[ATOMICRMW_FADD]](s32)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
%0:vgpr(p3) = COPY $vgpr0
%1:vgpr(s32) = COPY $vgpr1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
%2:vgpr(s32) = G_ATOMICRMW_FADD %0(p3), %1 :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
$vgpr0 = COPY %2
...
---
name: atomicrmw_fadd_s32_local_noret
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0, $vgpr1
AMDGPU/GlobalISel: Fix making LDS FP atomics legal on SI/CI
2020-06-05 03:21:20 +08:00
; GFX8-LABEL: name: atomicrmw_fadd_s32_local_noret
; GFX8: liveins: $vgpr0, $vgpr1
; GFX8: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GFX8: [[COPY1:%[0-9]+]]:vgpr_32 = COPY $vgpr1
; GFX8: $m0 = S_MOV_B32 -1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX8: [[DS_ADD_RTN_F32_:%[0-9]+]]:vgpr_32 = DS_ADD_RTN_F32 [[COPY]], [[COPY1]], 0, 0, implicit $m0, implicit $exec :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
; GFX9-LABEL: name: atomicrmw_fadd_s32_local_noret
; GFX9: liveins: $vgpr0, $vgpr1
; GFX9: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GFX9: [[COPY1:%[0-9]+]]:vgpr_32 = COPY $vgpr1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX9: [[DS_ADD_RTN_F32_gfx9_:%[0-9]+]]:vgpr_32 = DS_ADD_RTN_F32_gfx9 [[COPY]], [[COPY1]], 0, 0, implicit $exec :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Fix test failure in release build The annoying behavior where the output is different due to the legality check struck again, plus the subtarget predicate wasn't really correctly set for DS FP atomics. Some of the FP min/max instructions seem to be in the gfx6/gfx7 manuals, but IIRC this might have been one of the cases where the manual got ahead of the actual hardware support, but I've left these as-is for now since the assembler tests seem to expect them.
2020-06-06 22:31:08 +08:00
; GFX6-LABEL: name: atomicrmw_fadd_s32_local_noret
; GFX6: liveins: $vgpr0, $vgpr1
; GFX6: [[COPY:%[0-9]+]]:vgpr(p3) = COPY $vgpr0
; GFX6: [[COPY1:%[0-9]+]]:vgpr(s32) = COPY $vgpr1
; GFX6: $m0 = S_MOV_B32 -1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX6: [[ATOMICRMW_FADD:%[0-9]+]]:vgpr(s32) = G_ATOMICRMW_FADD [[COPY]](p3), [[COPY1]] :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
%0:vgpr(p3) = COPY $vgpr0
%1:vgpr(s32) = COPY $vgpr1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
%2:vgpr(s32) = G_ATOMICRMW_FADD %0(p3), %1 :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
...
---
name: atomicrmw_fadd_s32_local_gep4
legalized: true
regBankSelected: true
tracksRegLiveness: true
body: |
bb.0:
liveins: $vgpr0, $vgpr1
AMDGPU/GlobalISel: Fix making LDS FP atomics legal on SI/CI
2020-06-05 03:21:20 +08:00
; GFX8-LABEL: name: atomicrmw_fadd_s32_local_gep4
; GFX8: liveins: $vgpr0, $vgpr1
; GFX8: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GFX8: [[COPY1:%[0-9]+]]:vgpr_32 = COPY $vgpr1
; GFX8: $m0 = S_MOV_B32 -1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX8: [[DS_ADD_RTN_F32_:%[0-9]+]]:vgpr_32 = DS_ADD_RTN_F32 [[COPY]], [[COPY1]], 4, 0, implicit $m0, implicit $exec :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Fix making LDS FP atomics legal on SI/CI
2020-06-05 03:21:20 +08:00
; GFX8: $vgpr0 = COPY [[DS_ADD_RTN_F32_]]
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
; GFX9-LABEL: name: atomicrmw_fadd_s32_local_gep4
; GFX9: liveins: $vgpr0, $vgpr1
; GFX9: [[COPY:%[0-9]+]]:vgpr_32 = COPY $vgpr0
; GFX9: [[COPY1:%[0-9]+]]:vgpr_32 = COPY $vgpr1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX9: [[DS_ADD_RTN_F32_gfx9_:%[0-9]+]]:vgpr_32 = DS_ADD_RTN_F32_gfx9 [[COPY]], [[COPY1]], 4, 0, implicit $exec :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
; GFX9: $vgpr0 = COPY [[DS_ADD_RTN_F32_gfx9_]]
AMDGPU/GlobalISel: Fix test failure in release build The annoying behavior where the output is different due to the legality check struck again, plus the subtarget predicate wasn't really correctly set for DS FP atomics. Some of the FP min/max instructions seem to be in the gfx6/gfx7 manuals, but IIRC this might have been one of the cases where the manual got ahead of the actual hardware support, but I've left these as-is for now since the assembler tests seem to expect them.
2020-06-06 22:31:08 +08:00
; GFX6-LABEL: name: atomicrmw_fadd_s32_local_gep4
; GFX6: liveins: $vgpr0, $vgpr1
; GFX6: [[COPY:%[0-9]+]]:vgpr(p3) = COPY $vgpr0
; GFX6: [[COPY1:%[0-9]+]]:vgpr(s32) = COPY $vgpr1
; GFX6: [[C:%[0-9]+]]:vgpr(s32) = G_CONSTANT i32 4
; GFX6: [[PTR_ADD:%[0-9]+]]:vgpr(p3) = G_PTR_ADD [[COPY]], [[C]](s32)
; GFX6: $m0 = S_MOV_B32 -1
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
; GFX6: [[ATOMICRMW_FADD:%[0-9]+]]:vgpr_32(s32) = G_ATOMICRMW_FADD [[PTR_ADD]](p3), [[COPY1]] :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Fix test failure in release build The annoying behavior where the output is different due to the legality check struck again, plus the subtarget predicate wasn't really correctly set for DS FP atomics. Some of the FP min/max instructions seem to be in the gfx6/gfx7 manuals, but IIRC this might have been one of the cases where the manual got ahead of the actual hardware support, but I've left these as-is for now since the assembler tests seem to expect them.
2020-06-06 22:31:08 +08:00
; GFX6: $vgpr0 = COPY [[ATOMICRMW_FADD]](s32)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
%0:vgpr(p3) = COPY $vgpr0
%1:vgpr(s32) = COPY $vgpr1
%2:vgpr(s32) = G_CONSTANT i32 4
[globalisel] Rename G_GEP to G_PTR_ADD Summary: G_GEP is rather poorly named. It's a simple pointer+scalar addition and doesn't support any of the complexities of getelementptr. I therefore propose that we rename it. There's a G_PTR_MASK so let's follow that convention and go with G_PTR_ADD Reviewers: volkan, aditya_nandakumar, bogner, rovka, arsenm Subscribers: sdardis, jvesely, wdng, nhaehnle, hiraditya, jrtc27, atanasyan, arphaman, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69734
2019-11-02 04:18:00 +08:00
%3:vgpr(p3) = G_PTR_ADD %0, %2
CodeGen: Print/parse LLTs in MachineMemOperands This will currently accept the old number of bytes syntax, and convert it to a scalar. This should be removed in the near future (I think I converted all of the tests already, but likely missed a few). Not sure what the exact syntax and policy should be. We can continue printing the number of bytes for non-generic instructions to avoid test churn and only allow non-scalar types for generic instructions. This will currently print the LLT in parentheses, but accept parsing the existing integers and implicitly converting to scalar. The parentheses are a bit ugly, but the parser logic seems unable to deal without either parentheses or some keyword to indicate the start of a type.
2021-05-20 10:25:51 +08:00
%4:vgpr(s32) = G_ATOMICRMW_FADD %3(p3), %1 :: (load store seq_cst (s32), addrspace 3)
AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD llvm-svn: 367509
2019-08-01 11:33:15 +08:00
$vgpr0 = COPY %4
...