maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/init-invariant.cpp

61 lines
1.6 KiB
C++
Raw Normal View History

Don't pass -O0 to clang_cc1, it is the default. llvm-svn: 189910
2013-09-04 12:12:25 +08:00
// RUN: %clang_cc1 -triple i686-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix=CHECK-O0
Don't emit optimization-specific intrinsic at -O0. llvm-svn: 150838
2012-02-18 04:12:52 +08:00
// RUN: %clang_cc1 -triple i686-linux-gnu -emit-llvm %s -O1 -o - | FileCheck %s
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
Clang changes for overloading invariant.start and end intrinsics This change depends on the corresponding LLVM change at: https://reviews.llvm.org/D22519 The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this LLVM change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. llvm-svn: 276448
2016-07-23 01:50:08 +08:00
// Check that we add an llvm.invariant.start.p0i8 to mark when a global becomes
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
// read-only. If globalopt can fold the initializer, it will then mark the
// variable as constant.
Don't emit optimization-specific intrinsic at -O0. llvm-svn: 150838
2012-02-18 04:12:52 +08:00
// Do not produce markers at -O0.
Clang changes for overloading invariant.start and end intrinsics This change depends on the corresponding LLVM change at: https://reviews.llvm.org/D22519 The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this LLVM change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. llvm-svn: 276448
2016-07-23 01:50:08 +08:00
// CHECK-O0-NOT: llvm.invariant.start.p0i8
Don't emit optimization-specific intrinsic at -O0. llvm-svn: 150838
2012-02-18 04:12:52 +08:00
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
struct A {
Don't emit optimization-specific intrinsic at -O0. llvm-svn: 150838
2012-02-18 04:12:52 +08:00
A();
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
int n;
};
// CHECK: @a = global {{.*}} zeroinitializer
extern const A a = A();
struct B {
Don't emit optimization-specific intrinsic at -O0. llvm-svn: 150838
2012-02-18 04:12:52 +08:00
B();
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
mutable int n;
};
// CHECK: @b = global {{.*}} zeroinitializer
extern const B b = B();
struct C {
Don't emit optimization-specific intrinsic at -O0. llvm-svn: 150838
2012-02-18 04:12:52 +08:00
C();
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
~C();
int n;
};
// CHECK: @c = global {{.*}} zeroinitializer
extern const C c = C();
Don't emit optimization-specific intrinsic at -O0. llvm-svn: 150838
2012-02-18 04:12:52 +08:00
int f();
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
// CHECK: @d = global i32 0
extern const int d = f();
void e() {
static const A a = A();
}
Revert "[CodeGenCXX] Treat 'this' as noalias in constructors" This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
2018-10-15 23:43:00 +08:00
// CHECK: call void @_ZN1AC1Ev({{.*}}* nonnull @a)
Clang changes for overloading invariant.start and end intrinsics This change depends on the corresponding LLVM change at: https://reviews.llvm.org/D22519 The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this LLVM change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. llvm-svn: 276448
2016-07-23 01:50:08 +08:00
// CHECK: call {{.*}}@llvm.invariant.start.p0i8(i64 4, i8* bitcast ({{.*}} @a to i8*))
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
Revert "[CodeGenCXX] Treat 'this' as noalias in constructors" This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
2018-10-15 23:43:00 +08:00
// CHECK: call void @_ZN1BC1Ev({{.*}}* nonnull @b)
Clang changes for overloading invariant.start and end intrinsics This change depends on the corresponding LLVM change at: https://reviews.llvm.org/D22519 The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this LLVM change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. llvm-svn: 276448
2016-07-23 01:50:08 +08:00
// CHECK-NOT: call {{.*}}@llvm.invariant.start.p0i8(i64 4, i8* bitcast ({{.*}} @b to i8*))
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
Revert "[CodeGenCXX] Treat 'this' as noalias in constructors" This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
2018-10-15 23:43:00 +08:00
// CHECK: call void @_ZN1CC1Ev({{.*}}* nonnull @c)
Clang changes for overloading invariant.start and end intrinsics This change depends on the corresponding LLVM change at: https://reviews.llvm.org/D22519 The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this LLVM change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. llvm-svn: 276448
2016-07-23 01:50:08 +08:00
// CHECK-NOT: call {{.*}}@llvm.invariant.start.p0i8(i64 4, i8* bitcast ({{.*}} @c to i8*))
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
// CHECK: call i32 @_Z1fv(
// CHECK: store {{.*}}, i32* @d
Clang changes for overloading invariant.start and end intrinsics This change depends on the corresponding LLVM change at: https://reviews.llvm.org/D22519 The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this LLVM change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. llvm-svn: 276448
2016-07-23 01:50:08 +08:00
// CHECK: call {{.*}}@llvm.invariant.start.p0i8(i64 4, i8* bitcast ({{.*}} @d to i8*))
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-LABEL: define void @_Z1ev(
Revert "[CodeGenCXX] Treat 'this' as noalias in constructors" This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
2018-10-15 23:43:00 +08:00
// CHECK: call void @_ZN1AC1Ev(%struct.A* nonnull @_ZZ1evE1a)
Clang changes for overloading invariant.start and end intrinsics This change depends on the corresponding LLVM change at: https://reviews.llvm.org/D22519 The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this LLVM change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. llvm-svn: 276448
2016-07-23 01:50:08 +08:00
// CHECK: call {{.*}}@llvm.invariant.start.p0i8(i64 4, i8* {{.*}}bitcast ({{.*}} @_ZZ1evE1a to i8*))
The clang half of r150794: after the construction of a global or static const variable ends, if the variable has a trivial destructor and no mutable subobjects then emit an llvm.invariant.start call for it. globalopt knows to make the variable const when evaluating this. llvm-svn: 150798
2012-02-17 15:31:37 +08:00
// CHECK-NOT: llvm.invariant.end