| 7dcdf5ba9324a9577461eae302e88fdd52e310c5 |
|
06-May-2011 |
Eli Friedman <eli.friedman@gmail.com> |
Add an implementation of thunks for varargs methods. The implementation is a bit messy, but it is correct as long as the method in question doesn't use indirect gotos. A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 .
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130993 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| 15e310a3b970b64a84cb30f0005bc396b4d978cb |
|
19-Feb-2011 |
John McCall <rjmccall@apple.com> |
Warn about code that uses variables and functions with internal linkage
without defining them. This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition. I'll revisit later.
Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake. Doing so produces an invalid module
if the variable is not ultimately defined.
Also, fix several places in the test suite where we were using internal
functions without definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126016 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| 4e3b17c9ce4a198eaeac4355b12e4b523185ecb5 |
|
09-Nov-2010 |
John McCall <rjmccall@apple.com> |
When re-using a vtable slot for the nearest overridden method, just because
there's no return adjustment from the overridden to the overrider doesn't
mean there isn't a return adjustment from the overrider to the final
overrider. This matters if we're emitting a virtual this-adjustment thunk
because the overrider virtually inherits from the class providing the
nearest overridden method. Do the appropriate return adjustment in this case.
Fixes PR7611.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118466 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| 279b5eb6910d64a293e9c0e2887a05c65d8737d7 |
|
13-Aug-2010 |
John McCall <rjmccall@apple.com> |
Just disable the hidden-visibility optimization for now by hiding it behind
a -cc1 option. The Darwin linker complains about mixed visibility when linking
gcc-built objects with clang-built objects, and the optimization isn't really
that valuable. Platforms with less ornery linkers can feel free to enable this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110979 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| 65005536dee9216b14e2361153a14ddd8a7cd50a |
|
05-Aug-2010 |
John McCall <rjmccall@apple.com> |
Extend the visibility-hidden optimization to linkonce_odr thunks for
functions with in-line definitions, since such thunks will be emitted at any
use of the function.
Completes the feature work for rdar://problem/7523229.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110285 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| e21323588b32caf674213c9897dd12e2f0ea3cc5 |
|
02-Jun-2010 |
John McCall <rjmccall@apple.com> |
Don't try to emit the vtable for a class just because we're emitting a
virtual function from it.
Fixes PR7241.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105345 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| 2736071ea3a46f90e65c93418961611d96c10ab9 |
|
27-May-2010 |
John McCall <rjmccall@apple.com> |
Correctly pass aggregates by reference when emitting thunks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104778 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| 663218b576d8d79dea546c5726d7c90c216b1358 |
|
21-May-2010 |
Douglas Gregor <dgregor@apple.com> |
When generating the call arguments in a thunk to call the thunkee, do
not make copies non-POD arguments or arguments passed by reference:
just copy the pointers directly. This eliminates another source of the
dreaded memcpy-of-non-PODs. Fixes PR7188.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104327 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| cb359df81b83dd4f938d05cb9cf5c34bd20068bd |
|
20-May-2010 |
Douglas Gregor <dgregor@apple.com> |
When creating a this-adjustment thunk where the return value is of C++
class type (that uses a return slot), pass the return slot to the
callee directly rather than allocating new storage and trying to copy
the object. This appears to have been the cause of the remaining two
Boost.Interprocess failures.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104215 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| 6fb745bdf1ff1e32caf07e42093a7920726892c1 |
|
13-May-2010 |
Douglas Gregor <dgregor@apple.com> |
Rework when and how vtables are emitted, by tracking where vtables are
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions.
The new scheme:
- For every use of a vtable, Sema calls MarkVTableUsed() to indicate
the use. For example, this occurs when calling a virtual member
function of the class, defining a constructor of that class type,
dynamic_cast'ing from that type to a derived class, casting
to/through a virtual base class, etc.
- For every definition of a vtable, Sema calls MarkVTableUsed() to
indicate the definition. This happens at the end of the translation
unit for classes whose key function has been defined (so we can
delay computation of the key function; see PR6564), and will also
occur with explicit template instantiation definitions.
- For every vtable defined/used, we mark all of the virtual member
functions of that vtable as defined/used, unless we know that the key
function is in another translation unit. This instantiates virtual
member functions when needed.
- At the end of the translation unit, Sema tells CodeGen (via the
ASTConsumer) which vtables must be defined (CodeGen will define
them) and which may be used (for which CodeGen will define the
vtables lazily).
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
(1) There's a ton of churn in the tests, because the order in which
vtables get emitted to IR has changed. I've tried to isolate some of
the larger tests from these issues.
(2) Some diagnostics related to
implicitly-instantiated/implicitly-defined virtual member functions
have moved to the point of first use/definition. It's better this
way.
(3) I could use a review of the places where we MarkVTableUsed, to
see if I missed any place where the language effectively requires a
vtable.
Fixes PR7114 and PR6564.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103718 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| ada087c4518a18f844ecc051b07039064016a4ba |
|
27-Mar-2010 |
Anders Carlsson <andersca@mac.com> |
Give thunks the same linkage as their original methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99729 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|
| d63fed48fa958ca7d9a432dab1010c272c19f215 |
|
24-Mar-2010 |
Anders Carlsson <andersca@mac.com> |
Flip the switch and use the new vtable layout code for thunks by default. Add a thunks.cpp test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99367 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CodeGenCXX/thunks.cpp
|