e5ec21c977
Change CollectPrimaryBases to collect the bases in the right order. Fixes one half of PR9660.
...
llvm-svn: 129252
2011-04-10 18:00:32 +00:00
24b89469ac
'const std::type_info*' instead of 'std::type_info const*'
...
llvm-svn: 113092
2010-09-05 00:17:29 +00:00
88d292ccb8
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.
llvm-svn: 103718
2010-05-13 16:44:06 +00:00
c6db5ab8b2
Fix a bug where we would sometimes incorrectly mark an vtable function as unused.
...
llvm-svn: 101643
2010-04-17 17:24:33 +00:00
ea7b18298e
Split adding the primary virtual base offsets out into a separate pass. This fixes a bug where we would lay out virtual bases in the wrong order.
...
llvm-svn: 101373
2010-04-15 16:12:58 +00:00
7ff88f8b00
Typo.
...
llvm-svn: 101015
2010-04-12 05:32:01 +00:00
3383e2ad74
Fix another bug where we wouldn't generate secondary vtables for construction vtables in some cases.
...
llvm-svn: 100998
2010-04-11 22:20:36 +00:00
343a26b56d
Fix a bug where we were adding too many vcall offsets in some cases.
...
llvm-svn: 100985
2010-04-11 20:04:11 +00:00
7a148f7141
Fix another vbase layout bug.
...
llvm-svn: 100952
2010-04-10 21:35:33 +00:00
88cf34f2b4
Fix a bug where we would add the same function twice in a vtable.
...
llvm-svn: 100949
2010-04-10 20:39:29 +00:00
291279e3a6
Simplify the virtual base layout code and fix a bug where we wouldn't store the offset for a virtual base.
...
llvm-svn: 100940
2010-04-10 18:42:27 +00:00
eba1a60ef0
Another vtable layout fix, making us match gcc better.
...
llvm-svn: 99812
2010-03-29 15:08:41 +00:00
151b062fee
Don't add address points for virtual primary bases that aren't primary bases in the complete class.
...
llvm-svn: 99555
2010-03-25 21:45:14 +00:00
18c582d9c8
When dumping vtables, also dump the thunks.
...
llvm-svn: 98799
2010-03-18 02:44:19 +00:00
3521552ebe
Add a test.
...
llvm-svn: 98246
2010-03-11 06:44:31 +00:00
423406f335
Fix calculation of whether a member function needs a thunk in construction vtables.
...
llvm-svn: 98191
2010-03-10 21:25:37 +00:00
115b4756b5
We were mistakenly marking morally virtual bases as being uninteresting. Fix this.
...
llvm-svn: 98180
2010-03-10 19:39:11 +00:00
703a08605f
Ignore non-interesting bases when emitting construction vtables.
...
llvm-svn: 98177
2010-03-10 19:15:26 +00:00
45be0e069d
Add newline.
...
llvm-svn: 98140
2010-03-10 06:51:56 +00:00
804cf51dcf
Don't accidentally mark some functions in construction vtables as unused. Also land the test for a previous checkin, now that it's correct.
...
llvm-svn: 98139
2010-03-10 06:51:42 +00:00
5b0057c05b
Fix a bug with base offset merging that Devang noticed.
...
llvm-svn: 97641
2010-03-03 04:58:02 +00:00
7162ab947b
Handle unused functions in construction vtables correctly.
...
llvm-svn: 97406
2010-02-28 18:37:33 +00:00
8b37bb7c48
When laying out vtables for virtual bases in construction vtables, we need to check if the vtable is a primary base in the layout class.
...
llvm-svn: 97402
2010-02-28 18:08:38 +00:00
b15d8c57ad
Add another construction vtable test.
...
llvm-svn: 97401
2010-02-28 17:59:36 +00:00
e3385f566b
More improvements to construction vtables; we know handle vbase offsets correctly (I hope).
...
llvm-svn: 97361
2010-02-28 01:43:58 +00:00
c3f92a16f2
Add a simple construction vtable test.
...
llvm-svn: 97344
2010-02-27 21:09:00 +00:00
e02a926a1c
Use the real base offset when calculating vbase offsets.
...
llvm-svn: 97338
2010-02-27 19:21:58 +00:00
2b381bbb5c
Don't add this adjustments for pure virtual member functions.
...
llvm-svn: 97334
2010-02-27 18:16:50 +00:00
e6528ed7c5
Add another test.
...
llvm-svn: 97329
2010-02-27 16:55:58 +00:00
4068798cbc
Finish up the changes to this adjustments.
...
llvm-svn: 97328
2010-02-27 16:52:49 +00:00
d2025417ef
Fix another vtable layout bug; we weren't looking hard enough for overriden functions when determining if an overrider will ever be used.
...
llvm-svn: 97306
2010-02-27 06:38:03 +00:00
d69b2f93ea
Handle vcall offset sharing between destructors.
...
llvm-svn: 97304
2010-02-27 04:12:52 +00:00
b08aaa3e10
Fix a bug where we were generating an unnecessary vtable for a virtual base that's already a primary virtual base.
...
llvm-svn: 97303
2010-02-27 04:05:52 +00:00
ed7d0e8be8
Fux a bug where we were trying to add overriders for non-virtual bases of virtual bases more than once.
...
llvm-svn: 97173
2010-02-25 22:18:35 +00:00
0570f71255
More fixes. Don't try to emit a virtual base vtable if the virtual base in question is a primary virtual base of some other base.
...
llvm-svn: 96881
2010-02-23 03:48:14 +00:00
bae46277fe
Always emit vcall offset for the primary base, not only if it's virtual. Remove a debug printf, and add the test case that now passes.
...
llvm-svn: 96880
2010-02-23 03:26:17 +00:00
13f0f66223
Handle layout of vtables for virtual bases.
...
llvm-svn: 96355
2010-02-16 16:49:35 +00:00
14157939ab
Fix a bug where we would not emit secondary vtables for bases of a primary base.
...
llvm-svn: 96351
2010-02-16 16:02:57 +00:00
77904f1d5b
Emit vbase offsets.
...
llvm-svn: 96329
2010-02-16 04:59:55 +00:00
033d48697f
Don't compute final overriders or build vtables for bases that don't need a vtable.
...
llvm-svn: 96171
2010-02-14 17:05:59 +00:00
258a1e35e8
Improve support for non-virtual 'this' pointer adjustments. With this, it should be possible to use the new vtable layout code for all class hierarchies that do not involve virtual bases.
...
llvm-svn: 96137
2010-02-14 00:16:19 +00:00
d3adb0ced9
Add basic support for simple non-virtual 'this' pointer adjustments.
...
llvm-svn: 96136
2010-02-13 23:40:17 +00:00
e75aaa97b3
Start laying out secondary vtables.
...
llvm-svn: 96123
2010-02-13 22:05:23 +00:00
c1290adab7
Don't make return adjustments for pure virtual member functions.
...
llvm-svn: 96120
2010-02-13 21:16:54 +00:00
cf5a882da1
Handle virtual bases in return adjustment types.
...
llvm-svn: 96119
2010-02-13 21:07:32 +00:00
6a6cbfc55f
More work on covariant return types. We now handle non-virtual adjustments fine.
...
llvm-svn: 96114
2010-02-13 20:11:51 +00:00
e8a9756e63
Keep track of the address points for all primary bases, and add the ability to dump multiple address points for a single offset.
...
llvm-svn: 95970
2010-02-12 07:43:48 +00:00
84c416b9f6
Fix a bug causing an assertion when a covariant return type differed from
...
an overriden type only by reduced qualification.
llvm-svn: 95968
2010-02-12 06:15:07 +00:00
65b4978f7f
More work on vtable layout. We can now layout vtables with primary bases.
...
llvm-svn: 95965
2010-02-12 05:25:12 +00:00
09da3372b6
When dumping vtables, dump whether a virtual member function is pure or not.
...
llvm-svn: 95963
2010-02-12 02:38:13 +00:00
Anders Carlsson