RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 20:23:11 +01:00
Code Issues Projects Releases Wiki Activity
ba012f02f8
llvm-mirror/test/CodeGen/RISCV/vector-abi.ll

50 lines
2.7 KiB
LLVM
Raw Normal View History

[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RUN: llc -mtriple=riscv32 -stop-after finalize-isel < %s | FileCheck %s -check-prefix=RV32
; RUN: llc -mtriple=riscv64 -stop-after finalize-isel < %s | FileCheck %s -check-prefix=RV64
declare void @callee(<4 x i8> %v)
define void @caller() {
; RV32-LABEL: name: caller
; RV32: stack:
[RISCV] Fix stack slot for argument types (Bug 49500) This is an complementary/alternative fix for D99068. It takes a slightly different approach by explicitly summing up all of the required split part type sizes and ensuring we allocate enough space for them. It also takes the maximum alignment of each part. Compared with D99068 there are fewer changes to the stack objects in existing tests. However, @luismarques has shown in that patch that there are opportunities to reduce our stack usage in the future. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D99087
2021-03-22 16:54:04 +01:00
; RV32: - { id: 0, name: '', type: default, offset: 0, size: 16, alignment: 4,
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV32-NEXT: stack-id: default, callee-saved-register: '', callee-saved-restored: true,
; RV32-NEXT: debug-info-variable: '', debug-info-expression: '', debug-info-location: '' }
; RV32: bb.0 (%ir-block.0):
; RV32: ADJCALLSTACKDOWN 0, 0, implicit-def dead $x2, implicit $x2
; RV32: [[ADDI:%[0-9]+]]:gpr = ADDI $x0, 7
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 04:25:51 +02:00
; RV32: SW killed [[ADDI]], %stack.0, 12 :: (store (s32) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV32: [[ADDI1:%[0-9]+]]:gpr = ADDI $x0, 6
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 04:25:51 +02:00
; RV32: SW killed [[ADDI1]], %stack.0, 8 :: (store (s32) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV32: [[ADDI2:%[0-9]+]]:gpr = ADDI $x0, 5
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 04:25:51 +02:00
; RV32: SW killed [[ADDI2]], %stack.0, 4 :: (store (s32) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV32: [[ADDI3:%[0-9]+]]:gpr = ADDI $x0, 4
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 04:25:51 +02:00
; RV32: SW killed [[ADDI3]], %stack.0, 0 :: (store (s32) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV32: [[ADDI4:%[0-9]+]]:gpr = ADDI %stack.0, 0
; RV32: $x10 = COPY [[ADDI4]]
; RV32: PseudoCALL target-flags(riscv-plt) @callee, csr_ilp32_lp64, implicit-def dead $x1, implicit $x10, implicit-def $x2
; RV32: ADJCALLSTACKUP 0, 0, implicit-def dead $x2, implicit $x2
; RV32: PseudoRET
; RV64-LABEL: name: caller
; RV64: stack:
[RISCV] Fix stack slot for argument types (Bug 49500) This is an complementary/alternative fix for D99068. It takes a slightly different approach by explicitly summing up all of the required split part type sizes and ensuring we allocate enough space for them. It also takes the maximum alignment of each part. Compared with D99068 there are fewer changes to the stack objects in existing tests. However, @luismarques has shown in that patch that there are opportunities to reduce our stack usage in the future. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D99087
2021-03-22 16:54:04 +01:00
; RV64: - { id: 0, name: '', type: default, offset: 0, size: 32, alignment: 8,
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV64-NEXT: stack-id: default, callee-saved-register: '', callee-saved-restored: true,
; RV64-NEXT: debug-info-variable: '', debug-info-expression: '', debug-info-location: '' }
; RV64: bb.0 (%ir-block.0):
; RV64: ADJCALLSTACKDOWN 0, 0, implicit-def dead $x2, implicit $x2
; RV64: [[ADDI:%[0-9]+]]:gpr = ADDI $x0, 7
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 04:25:51 +02:00
; RV64: SD killed [[ADDI]], %stack.0, 24 :: (store (s64) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV64: [[ADDI1:%[0-9]+]]:gpr = ADDI $x0, 6
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 04:25:51 +02:00
; RV64: SD killed [[ADDI1]], %stack.0, 16 :: (store (s64) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV64: [[ADDI2:%[0-9]+]]:gpr = ADDI $x0, 5
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 04:25:51 +02:00
; RV64: SD killed [[ADDI2]], %stack.0, 8 :: (store (s64) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV64: [[ADDI3:%[0-9]+]]:gpr = ADDI $x0, 4
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 04:25:51 +02:00
; RV64: SD killed [[ADDI3]], %stack.0, 0 :: (store (s64) into %stack.0)
[RISCV] Add a test showing incorrect codegen This patch adds a test which shows how the compiler incorrectly sets the size and alignment of a stack object used to indirectly pass vector types to functions. In the particular example, the test passes a <4 x i8> vector type to a function and creates a stack object of size and alignment equal to 4 bytes. However, the code generated to set up that parameter has been scalarized and stores each element as individual XLEN-sized values. Thus on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber the stack. Similarly, the alignment is set up as the alignment of the vector type, which is not necessarily the natural alignment of XLEN. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D95025
2021-01-20 08:49:53 +01:00
; RV64: [[ADDI4:%[0-9]+]]:gpr = ADDI %stack.0, 0
; RV64: $x10 = COPY [[ADDI4]]
; RV64: PseudoCALL target-flags(riscv-plt) @callee, csr_ilp32_lp64, implicit-def dead $x1, implicit $x10, implicit-def $x2
; RV64: ADJCALLSTACKUP 0, 0, implicit-def dead $x2, implicit $x2
; RV64: PseudoRET
call void @callee(<4 x i8> <i8 4, i8 5, i8 6, i8 7>)
ret void
}
Reference in New Issue Copy Permalink