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/amdgcn-large-globals.cl

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

13 lines
507 B
Common Lisp
Raw Normal View History

Fix array sizes where address space is not yet known For variables in generic address spaces, for example: ``` unsigned char V[6442450944]; ... ``` the address space is not yet known when we get into *getConstantArrayType*, it is 0. AMDGCN target's address space 0 has 32 bits pointers, so when we call *getPointerWidth* with 0, the array size is trimmed to 32 bits, which is not right. Differential Revision: https://reviews.llvm.org/D30845 llvm-svn: 298420
2017-03-22 02:55:39 +08:00
// REQUIRES: amdgpu-registered-target
// RUN: %clang_cc1 -cl-std=CL2.0 -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck %s
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK: @One ={{.*}} local_unnamed_addr addrspace(1) global [6442450944 x i8] zeroinitializer, align 1
Fix array sizes where address space is not yet known For variables in generic address spaces, for example: ``` unsigned char V[6442450944]; ... ``` the address space is not yet known when we get into *getConstantArrayType*, it is 0. AMDGCN target's address space 0 has 32 bits pointers, so when we call *getPointerWidth* with 0, the array size is trimmed to 32 bits, which is not right. Differential Revision: https://reviews.llvm.org/D30845 llvm-svn: 298420
2017-03-22 02:55:39 +08:00
unsigned char One[6442450944];
[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences For a default visibility external linkage definition, dso_local is set for ELF -fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences. To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition, which sets dso_local for default visibility external linkage definitions. To make this flip smooth and enable future (dso_local as definition default), this patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 16:27:11 +08:00
// CHECK: @Two ={{.*}} local_unnamed_addr addrspace(1) global [6442450944 x i32] zeroinitializer, align 4
Fix array sizes where address space is not yet known For variables in generic address spaces, for example: ``` unsigned char V[6442450944]; ... ``` the address space is not yet known when we get into *getConstantArrayType*, it is 0. AMDGCN target's address space 0 has 32 bits pointers, so when we call *getPointerWidth* with 0, the array size is trimmed to 32 bits, which is not right. Differential Revision: https://reviews.llvm.org/D30845 llvm-svn: 298420
2017-03-22 02:55:39 +08:00
global unsigned int Two[6442450944];
Recommit #2 "[Driver] Default to -fno-common for all targets" After a first attempt to fix the test-suite failures, my first recommit caused the same failures again. I had updated CMakeList.txt files of tests that needed -fcommon, but it turns out that there are also Makefiles which are used by some bots, so I've updated these Makefiles now too. See the original commit message for more details on this change: 0a9fc9233e172601e26381810d093e02ef410f65
2020-03-10 03:25:24 +08:00
Fix array sizes where address space is not yet known For variables in generic address spaces, for example: ``` unsigned char V[6442450944]; ... ``` the address space is not yet known when we get into *getConstantArrayType*, it is 0. AMDGCN target's address space 0 has 32 bits pointers, so when we call *getPointerWidth* with 0, the array size is trimmed to 32 bits, which is not right. Differential Revision: https://reviews.llvm.org/D30845 llvm-svn: 298420
2017-03-22 02:55:39 +08:00
kernel void large_globals(unsigned int id) {
One[id] = id;
Two[id + 1] = id + 1;
}