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
64f4a52b52
llvm-mirror/test/Assembler/call-nonzero-program-addrspace-2.ll

23 lines
1.0 KiB
LLVM
Raw Normal View History

Make the LLParser accept call instructions of variables in the program AS Summary: Since r325479 the DataLayout includes a program address space. However, it is not possible to use `call %foo` if foo is a `i8(...) addrspace(200)` and the DataLayout specifies address space 200 as the address space for functions. With this change the IR parser will still accept variables in the program address space as well as address space 0 for call and invoke functions. Reviewers: pcc, arsenm, bjope, dylanmckay, theraven Reviewed By: dylanmckay Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43645 llvm-svn: 326188
2018-02-27 12:15:11 +01:00
; RUN: not llvm-as %s -o /dev/null 2>&1 | FileCheck %s
Allow creating llvm::Function in non-zero address spaces Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
2018-08-23 11:25:17 +02:00
; RUN: llvm-as %s -data-layout=P42 -o - | llvm-dis - -o - | FileCheck %s -check-prefix PROGAS42
Make the LLParser accept call instructions of variables in the program AS Summary: Since r325479 the DataLayout includes a program address space. However, it is not possible to use `call %foo` if foo is a `i8(...) addrspace(200)` and the DataLayout specifies address space 200 as the address space for functions. With this change the IR parser will still accept variables in the program address space as well as address space 0 for call and invoke functions. Reviewers: pcc, arsenm, bjope, dylanmckay, theraven Reviewed By: dylanmckay Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43645 llvm-svn: 326188
2018-02-27 12:15:11 +01:00
; Check that numbered variables in a nonzero program address space 200 can be used in a call instruction
IR: print value numbers for unnamed function arguments For consistency with normal instructions and clarity when reading IR, it's best to print the %0, %1, ... names of function arguments in definitions. Also modifies the parser to accept IR in that form for obvious reasons. llvm-svn: 367755
2019-08-03 16:28:34 +02:00
define i8 @test_unnamed(i8(i32)*, i8(i32) addrspace(42)* %0) {
Allow creating llvm::Function in non-zero address spaces Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
2018-08-23 11:25:17 +02:00
; Calls with explicit address spaces are fine:
call addrspace(0) i8 %0(i32 0)
call addrspace(42) i8 %1(i32 0)
; this call is fine if the program address space is 42
call i8 %1(i32 0)
; CHECK: call-nonzero-program-addrspace-2.ll:[[@LINE-1]]:11: error: '%1' defined with type 'i8 (i32) addrspace(42)*' but expected 'i8 (i32)*'
Make the LLParser accept call instructions of variables in the program AS Summary: Since r325479 the DataLayout includes a program address space. However, it is not possible to use `call %foo` if foo is a `i8(...) addrspace(200)` and the DataLayout specifies address space 200 as the address space for functions. With this change the IR parser will still accept variables in the program address space as well as address space 0 for call and invoke functions. Reviewers: pcc, arsenm, bjope, dylanmckay, theraven Reviewed By: dylanmckay Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43645 llvm-svn: 326188
2018-02-27 12:15:11 +01:00
ret i8 0
}
Allow creating llvm::Function in non-zero address spaces Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
2018-08-23 11:25:17 +02:00
; PROGAS42: target datalayout = "P42"
IR: print value numbers for unnamed function arguments For consistency with normal instructions and clarity when reading IR, it's best to print the %0, %1, ... names of function arguments in definitions. Also modifies the parser to accept IR in that form for obvious reasons. llvm-svn: 367755
2019-08-03 16:28:34 +02:00
; PROGAS42: define i8 @test_unnamed(i8 (i32)* %0, i8 (i32) addrspace(42)* %1) addrspace(42) {
Allow creating llvm::Function in non-zero address spaces Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
2018-08-23 11:25:17 +02:00
; PROGAS42-NEXT: %3 = call addrspace(0) i8 %0(i32 0)
; PROGAS42-NEXT: %4 = call addrspace(42) i8 %1(i32 0)
; PROGAS42-NEXT: %5 = call addrspace(42) i8 %1(i32 0)
; PROGAS42-NEXT: ret i8 0
; PROGAS42-NEXT: }
Reference in New Issue Copy Permalink