maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Modules/cxx-irgen.cpp

77 lines
3.0 KiB
C++
Raw Normal View History

Emit an update record if we instantiate the definition of a function template specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
2014-03-23 07:33:22 +08:00
// RUN: rm -rf %t
Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'. Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
2016-12-23 08:23:01 +08:00
// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x objective-c++ -std=c++11 -fmodules-cache-path=%t -I %S/Inputs -triple %itanium_abi_triple -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x objective-c++ -std=c++11 -fmodules-cache-path=%t -I %S/Inputs -triple %itanium_abi_triple -disable-llvm-passes -emit-llvm -debug-info-kind=limited -o - %s | FileCheck %s
Emit an update record if we instantiate the definition of a function template specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
2014-03-23 07:33:22 +08:00
// FIXME: When we have a syntax for modules in C++, use that.
@import cxx_irgen_top;
When a module completes the definition of a class template specialization imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations. llvm-svn: 206680
2014-04-19 11:48:30 +08:00
CtorInit<int> x;
Emit an update record if we instantiate the definition of a function template specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
2014-03-23 07:33:22 +08:00
@import cxx_irgen_left;
@import cxx_irgen_right;
[modules] Fix a rejects-valid resulting from emitting an inline function recursively within the emission of another inline function. This ultimately led to us emitting the same inline function definition twice, which we then rejected because we believed we had a mangled name conflict. llvm-svn: 215579
2014-08-14 05:15:09 +08:00
// Keep these two namespace definitions separate; merging them hides the bug.
namespace EmitInlineMethods {
Fix a couple of tests in clang/test to match "x86_thiscallcc" introduced in r240971. llvm-svn: 241047
2015-06-30 16:02:26 +08:00
// CHECK-DAG: define linkonce_odr [[CC:([0-9_a-z]*cc[ ]+)?]]void @_ZN17EmitInlineMethods1C1fEPNS_1AE(
clang/test/Modules/cxx-irgen.cpp: Let it tolerant of x86_thiscallcc. llvm-svn: 215607
2014-08-14 08:23:30 +08:00
// CHECK-DAG: declare [[CC]]void @_ZN17EmitInlineMethods1A1gEv(
[modules] Fix a rejects-valid resulting from emitting an inline function recursively within the emission of another inline function. This ultimately led to us emitting the same inline function definition twice, which we then rejected because we believed we had a mangled name conflict. llvm-svn: 215579
2014-08-14 05:15:09 +08:00
struct C {
__attribute__((used)) void f(A *p) { p->g(); }
};
}
namespace EmitInlineMethods {
clang/test/Modules/cxx-irgen.cpp: Let it tolerant of x86_thiscallcc. llvm-svn: 215607
2014-08-14 08:23:30 +08:00
// CHECK-DAG: define linkonce_odr [[CC]]void @_ZN17EmitInlineMethods1D1fEPNS_1BE(
// CHECK-DAG: define linkonce_odr [[CC]]void @_ZN17EmitInlineMethods1B1gEv(
[modules] Fix a rejects-valid resulting from emitting an inline function recursively within the emission of another inline function. This ultimately led to us emitting the same inline function definition twice, which we then rejected because we believed we had a mangled name conflict. llvm-svn: 215579
2014-08-14 05:15:09 +08:00
struct D {
__attribute__((used)) void f(B *p) { p->g(); }
};
}
Revert "Always_inline codegen rewrite" and 2 follow-ups. Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs" Revert "Always_inline codegen rewrite." Reason for revert: PR24793. llvm-svn: 247620
2015-09-15 05:35:16 +08:00
// CHECK-DAG: define available_externally hidden {{.*}}{{signext i32|i32}} @_ZN1SIiE1gEv({{.*}} #[[ALWAYS_INLINE:.*]] align
Emit an update record if we instantiate the definition of a function template specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
2014-03-23 07:33:22 +08:00
int a = S<int>::g();
int b = h();
Account for calling convention specifiers in function definitions in IR test cases Several tests wouldn't pass when executed on an armv7a_pc_linux triple due to the non-default arm_aapcs calling convention produced on the function definitions in the IR output. Account for this with the application of a little regex. Patch by Ying Yi. llvm-svn: 240971
2015-06-30 01:29:50 +08:00
// CHECK-DAG: define linkonce_odr {{.*}}{{signext i32|i32}} @_Z3minIiET_S0_S0_(i32
If an update record makes a declaration interesting, pass it to the consumer. llvm-svn: 204550
2014-03-23 08:27:18 +08:00
int c = min(1, 2);
Revert "Always_inline codegen rewrite" and 2 follow-ups. Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs" Revert "Always_inline codegen rewrite." Reason for revert: PR24793. llvm-svn: 247620
2015-09-15 05:35:16 +08:00
// CHECK: define available_externally {{.*}}{{signext i32|i32}} @_ZN1SIiE1fEv({{.*}} #[[ALWAYS_INLINE]] align
[modules] When emitting an update record containing the body of a destructor, also emit the updated 'operator delete' looked up for that destructor. Switch from UpdateDecl to an actual update record when this happens due to implicitly defining a special member function and unify this code path and the one for instantiating a function definition. llvm-svn: 215132
2014-08-08 02:53:08 +08:00
[modules] Maintain an AST invariant across module load/save: if any declaration of a function has a resolved exception specification, then all declarations of the function do. We should probably improve the AST representation to make this implicit (perhaps only store the exception specification on the canonical declaration), but this fixes things for now. The testcase for this (which used to assert) also exposes the actual bug I was trying to reduce here: we sometimes fail to emit the body of an imported special member function definition. Fix for that to follow. llvm-svn: 214458
2014-08-01 07:46:44 +08:00
namespace ImplicitSpecialMembers {
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// CHECK-LABEL: define {{.*}} @_ZN22ImplicitSpecialMembers1BC2ERKS0_(
[modules] Maintain an AST invariant across module load/save: if any declaration of a function has a resolved exception specification, then all declarations of the function do. We should probably improve the AST representation to make this implicit (perhaps only store the exception specification on the canonical declaration), but this fixes things for now. The testcase for this (which used to assert) also exposes the actual bug I was trying to reduce here: we sometimes fail to emit the body of an imported special member function definition. Fix for that to follow. llvm-svn: 214458
2014-08-01 07:46:44 +08:00
// CHECK: call {{.*}} @_ZN22ImplicitSpecialMembers1AC1ERKS0_(
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// CHECK-LABEL: define {{.*}} @_ZN22ImplicitSpecialMembers1BC2EOS0_(
[modules] Maintain an AST invariant across module load/save: if any declaration of a function has a resolved exception specification, then all declarations of the function do. We should probably improve the AST representation to make this implicit (perhaps only store the exception specification on the canonical declaration), but this fixes things for now. The testcase for this (which used to assert) also exposes the actual bug I was trying to reduce here: we sometimes fail to emit the body of an imported special member function definition. Fix for that to follow. llvm-svn: 214458
2014-08-01 07:46:44 +08:00
// CHECK: call {{.*}} @_ZN22ImplicitSpecialMembers1AC1ERKS0_(
// CHECK-LABEL: define {{.*}} @_ZN22ImplicitSpecialMembers1CC2ERKS0_(
// CHECK: call {{.*}} @_ZN22ImplicitSpecialMembers1AC1ERKS0_(
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// CHECK-LABEL: define {{.*}} @_ZN22ImplicitSpecialMembers1CC2EOS0_(
[modules] Maintain an AST invariant across module load/save: if any declaration of a function has a resolved exception specification, then all declarations of the function do. We should probably improve the AST representation to make this implicit (perhaps only store the exception specification on the canonical declaration), but this fixes things for now. The testcase for this (which used to assert) also exposes the actual bug I was trying to reduce here: we sometimes fail to emit the body of an imported special member function definition. Fix for that to follow. llvm-svn: 214458
2014-08-01 07:46:44 +08:00
// CHECK: call {{.*}} @_ZN22ImplicitSpecialMembers1AC1ERKS0_(
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// CHECK-LABEL: define {{.*}} @_ZN22ImplicitSpecialMembers1DC2ERKS0_(
[modules] Remove IRGen special case for emitting implicit special members if they're somehow missing a body. Looks like this was left behind when the loop was generalized, and it's not been problematic before because without modules, a used, implicit special member function declaration must be a definition. This was resulting in us trying to emit a constructor declaration rather than a definition, and producing a constructor missing its member initializers. llvm-svn: 214473
2014-08-01 09:56:39 +08:00
// CHECK: call {{.*}} @_ZN22ImplicitSpecialMembers1AC1ERKS0_(
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// CHECK-LABEL: define {{.*}} @_ZN22ImplicitSpecialMembers1DC2EOS0_(
// CHECK: call {{.*}} @_ZN22ImplicitSpecialMembers1AC1ERKS0_(
// CHECK-LABEL: define {{.*}} @_ZN20OperatorDeleteLookup1AD0Ev(
Account for calling convention specifiers in function definitions in IR test cases Several tests wouldn't pass when executed on an armv7a_pc_linux triple due to the non-default arm_aapcs calling convention produced on the function definitions in the IR output. Account for this with the application of a little regex. Patch by Ying Yi. llvm-svn: 240971
2015-06-30 01:29:50 +08:00
// CHECK: call {{.*}}void @_ZN20OperatorDeleteLookup1AdlEPv(
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
Account for calling convention specifiers in function definitions in IR test cases Several tests wouldn't pass when executed on an armv7a_pc_linux triple due to the non-default arm_aapcs calling convention produced on the function definitions in the IR output. Account for this with the application of a little regex. Patch by Ying Yi. llvm-svn: 240971
2015-06-30 01:29:50 +08:00
// CHECK-DAG: call {{[a-z\_\d]*[ ]?i32}} @_ZN8CtorInitIiE1fEv(
[modules] Maintain an AST invariant across module load/save: if any declaration of a function has a resolved exception specification, then all declarations of the function do. We should probably improve the AST representation to make this implicit (perhaps only store the exception specification on the canonical declaration), but this fixes things for now. The testcase for this (which used to assert) also exposes the actual bug I was trying to reduce here: we sometimes fail to emit the body of an imported special member function definition. Fix for that to follow. llvm-svn: 214458
2014-08-01 07:46:44 +08:00
extern B b1;
B b2(b1);
B b3(static_cast<B&&>(b1));
extern C c1;
C c2(c1);
C c3(static_cast<C&&>(c1));
extern D d1;
D d2(d1);
D d3(static_cast<D&&>(d1));
}
[modules] When emitting an update record containing the body of a destructor, also emit the updated 'operator delete' looked up for that destructor. Switch from UpdateDecl to an actual update record when this happens due to implicitly defining a special member function and unify this code path and the one for instantiating a function definition. llvm-svn: 215132
2014-08-08 02:53:08 +08:00
namespace OperatorDeleteLookup {
// Trigger emission of B's vtable and deleting dtor.
// This requires us to know what operator delete was selected.
void g() { f(); }
}
[modules] Maintain an AST invariant across module load/save: if any declaration of a function has a resolved exception specification, then all declarations of the function do. We should probably improve the AST representation to make this implicit (perhaps only store the exception specification on the canonical declaration), but this fixes things for now. The testcase for this (which used to assert) also exposes the actual bug I was trying to reduce here: we sometimes fail to emit the body of an imported special member function definition. Fix for that to follow. llvm-svn: 214458
2014-08-01 07:46:44 +08:00
Emit an update record if we instantiate the definition of a function template specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
2014-03-23 07:33:22 +08:00
// CHECK: attributes #[[ALWAYS_INLINE]] = {{.*}} alwaysinline