maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenOpenCL/address-spaces-mangling.cl

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

63 lines
3.4 KiB
Common Lisp
Raw Normal View History

[OpenCL] Fixed addr space manging test. Fixed typo in the Filecheck directive and changed the test to verify output correctly. Fixes PR40029! llvm-svn: 352760
2019-01-31 23:23:48 +08:00
// RUN: %clang_cc1 %s -ffake-address-space-map -faddress-space-map-mangling=yes -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefixes="ASMANG,ASMANG10" %s
// RUN: %clang_cc1 %s -cl-std=CL2.0 -ffake-address-space-map -faddress-space-map-mangling=yes -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefixes="ASMANG,ASMANG20" %s
// RUN: %clang_cc1 %s -ffake-address-space-map -faddress-space-map-mangling=no -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefixes="NOASMANG,NOASMANG10" %s
// RUN: %clang_cc1 %s -cl-std=CL2.0 -ffake-address-space-map -faddress-space-map-mangling=no -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefixes="NOASMANG,NOASMANG20" %s
[OpenCL] Add support of __opencl_c_device_enqueue feature macro. This feature requires support of __opencl_c_generic_address_space and __opencl_c_program_scope_global_variables so diagnostics for that is provided as well. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D115640
2021-12-13 23:43:37 +08:00
// RUN: %clang_cc1 %s -cl-std=CL3.0 -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_generic_address_space -ffake-address-space-map -faddress-space-map-mangling=no -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefixes="NOASMANG,NOASMANG20" %s
// RUN: %clang_cc1 %s -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_generic_address_space -ffake-address-space-map -faddress-space-map-mangling=yes -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefixes="ASMANG,ASMANG20" %s
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
[OpenCL] Added a LIT test for ensuring address space mangling is done the same both in OpenCL1.2 and OpenCL2.0. Patch by Egor Churaev (echuraev). Reviewers: Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27403 llvm-svn: 288891
2016-12-07 16:43:49 +08:00
// We check that the address spaces are mangled the same in both version of OpenCL
// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL2.0 -emit-llvm -o - | FileCheck -check-prefix=OCL-20 %s
// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL1.2 -emit-llvm -o - | FileCheck -check-prefix=OCL-12 %s
[OpenCL] Add support of __opencl_c_device_enqueue feature macro. This feature requires support of __opencl_c_generic_address_space and __opencl_c_program_scope_global_variables so diagnostics for that is provided as well. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D115640
2021-12-13 23:43:37 +08:00
// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_generic_address_space -emit-llvm -o - | FileCheck -check-prefix=OCL-20 %s
// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL3.0 -cl-ext=-all -emit-llvm -o - | FileCheck -check-prefix=OCL-12 %s
// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=clc++2021 -cl-ext=-all,+__opencl_c_generic_address_space -emit-llvm -o - | FileCheck -check-prefix=OCL-20 %s
// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=clc++2021 -cl-ext=-all -emit-llvm -o - | FileCheck -check-prefix=OCL-12 %s
[OpenCL] Added a LIT test for ensuring address space mangling is done the same both in OpenCL1.2 and OpenCL2.0. Patch by Egor Churaev (echuraev). Reviewers: Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27403 llvm-svn: 288891
2016-12-07 16:43:49 +08:00
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
// We can't name this f as private is equivalent to default
// no specifier given address space so we get multiple definition
// warnings, but we do want it for comparison purposes.
__attribute__((overloadable))
void ff(int *arg) { }
[OpenCL] Add LangAS::opencl_private to represent private address space in AST Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
2017-10-13 11:37:48 +08:00
// ASMANG10: @_Z2ffPi
// ASMANG20: @_Z2ffPU3AS4i
[OpenCL] Fixed addr space manging test. Fixed typo in the Filecheck directive and changed the test to verify output correctly. Fixes PR40029! llvm-svn: 352760
2019-01-31 23:23:48 +08:00
// NOASMANG10: @_Z2ffPU9CLprivatei
[OpenCL] Add LangAS::opencl_private to represent private address space in AST Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
2017-10-13 11:37:48 +08:00
// NOASMANG20: @_Z2ffPU9CLgenerici
[OpenCL] Added a LIT test for ensuring address space mangling is done the same both in OpenCL1.2 and OpenCL2.0. Patch by Egor Churaev (echuraev). Reviewers: Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27403 llvm-svn: 288891
2016-12-07 16:43:49 +08:00
// OCL-20-DAG: @_Z2ffPU3AS4i
// OCL-12-DAG: @_Z2ffPi
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
__attribute__((overloadable))
void f(private int *arg) { }
// ASMANG: @_Z1fPi
[OpenCL] Add LangAS::opencl_private to represent private address space in AST Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
2017-10-13 11:37:48 +08:00
// NOASMANG: @_Z1fPU9CLprivatei
[OpenCL] Added a LIT test for ensuring address space mangling is done the same both in OpenCL1.2 and OpenCL2.0. Patch by Egor Churaev (echuraev). Reviewers: Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27403 llvm-svn: 288891
2016-12-07 16:43:49 +08:00
// OCL-20-DAG: @_Z1fPi
// OCL-12-DAG: @_Z1fPi
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
__attribute__((overloadable))
void f(global int *arg) { }
// ASMANG: @_Z1fPU3AS1i
// NOASMANG: @_Z1fPU8CLglobali
[OpenCL] Added a LIT test for ensuring address space mangling is done the same both in OpenCL1.2 and OpenCL2.0. Patch by Egor Churaev (echuraev). Reviewers: Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27403 llvm-svn: 288891
2016-12-07 16:43:49 +08:00
// OCL-20-DAG: @_Z1fPU3AS1i
// OCL-12-DAG: @_Z1fPU3AS1i
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
__attribute__((overloadable))
void f(local int *arg) { }
[OpenCL] Align fake address space map with the SPIR target maps. Summary: We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir. On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis. Reviewers: pekka.jaaskelainen, Anastasia Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits Differential Revision: https://reviews.llvm.org/D28048 llvm-svn: 290436
2016-12-24 00:11:25 +08:00
// ASMANG: @_Z1fPU3AS3i
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
// NOASMANG: @_Z1fPU7CLlocali
[OpenCL] Align fake address space map with the SPIR target maps. Summary: We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir. On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis. Reviewers: pekka.jaaskelainen, Anastasia Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits Differential Revision: https://reviews.llvm.org/D28048 llvm-svn: 290436
2016-12-24 00:11:25 +08:00
// OCL-20-DAG: @_Z1fPU3AS3i
// OCL-12-DAG: @_Z1fPU3AS3i
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
__attribute__((overloadable))
void f(constant int *arg) { }
[OpenCL] Align fake address space map with the SPIR target maps. Summary: We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir. On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis. Reviewers: pekka.jaaskelainen, Anastasia Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits Differential Revision: https://reviews.llvm.org/D28048 llvm-svn: 290436
2016-12-24 00:11:25 +08:00
// ASMANG: @_Z1fPU3AS2i
Certain multi-platform languages, such as OpenCL, have the concept of address spaces which is both (1) a "semantic" concept and (2) possibly a hardware level restriction. It is desirable to be able to discard/merge the LLVM-level address spaces on arguments for which there is no difference to the current backend while keeping track of the semantic address spaces in a funciton prototype. To do this enable addition of the address space into the name-mangling process. Add some tests to document this behaviour against inadvertent changes. Patch by Michele Scandale! llvm-svn: 190684
2013-09-13 20:04:22 +08:00
// NOASMANG: @_Z1fPU10CLconstanti
[OpenCL] Align fake address space map with the SPIR target maps. Summary: We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir. On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis. Reviewers: pekka.jaaskelainen, Anastasia Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits Differential Revision: https://reviews.llvm.org/D28048 llvm-svn: 290436
2016-12-24 00:11:25 +08:00
// OCL-20-DAG: @_Z1fPU3AS2i
// OCL-12-DAG: @_Z1fPU3AS2i
[OpenCL] Add LangAS::opencl_private to represent private address space in AST Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
2017-10-13 11:37:48 +08:00
[OpenCL] Add support of __opencl_c_generic_address_space feature macro Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D103401
2021-07-13 17:45:38 +08:00
#if (__OPENCL_C_VERSION__ == 200) || defined(__opencl_c_generic_address_space)
[OpenCL] Add LangAS::opencl_private to represent private address space in AST Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
2017-10-13 11:37:48 +08:00
__attribute__((overloadable))
void f(generic int *arg) { }
// ASMANG20: @_Z1fPU3AS4i
// NOASMANG20: @_Z1fPU9CLgenerici
// OCL-20-DAG: @_Z1fPU3AS4i
#endif