summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGVTables.h
Commit message (Collapse)AuthorAgeFilesLines
* [CodeGen] Remove dead code. NFC.Benjamin Kramer2015-10-151-4/+0
| | | | llvm-svn: 250418
* Header guard canonicalization, clang part.Benjamin Kramer2014-08-131-2/+2
| | | | | | Modifications made by clang-tidy with minor tweaks. llvm-svn: 215557
* MS ABI: Reference MSVC RTTI from the VFTableDavid Majnemer2014-07-011-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pointer for a class's RTTI data comes right before the VFTable but has no name. To be properly compatible with this, we do the following: * Create a single GlobalVariable which holds the contents of the VFTable _and_ the pointer to the RTTI data. * Create a GlobalAlias, with appropriate linkage/visibility, that points just after the RTTI data pointer. This ensures that the VFTable symbol will always refer to VFTable data. * Create a Comdat with a "Largest" SelectionKind and stick the private GlobalVariable in it. By transitivity, the GlobalAlias will be a member of the Comdat group. Using "Largest" ensures that foreign definitions without an RTTI data pointer will _not_ be chosen in the final linked image. Whether or not we emit RTTI data depends on several things: * The -fno-rtti flag implies that we should never not emit a pointer to RTTI data before the VFTable. * __declspec(dllimport) brings in the VFTable from a remote DLL. Use an available_externally GlobalVariable to provide a local definition of the VFTable. This means that we won't have any available_externally definitions of things like complete object locators. This is acceptable because they are never directly referenced. To my knowledge, this completes the implementation of MSVC RTTI code generation. Further semantic work should be done to properly support /GR-. llvm-svn: 212125
* Fix comment vs function name mismatchHans Wennborg2014-06-021-1/+1
| | | | llvm-svn: 210039
* MS ABI: Mangle member pointer template argumentsReid Kleckner2014-02-051-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Member pointers are mangled as they would be represented at runtime. They can be a single integer literal, single decl, or a tuple with some more numbers tossed in. With Clang today, most of those numbers will be zero because we reject pointers to members of virtual bases. This change required moving VTableContextBase ownership from CodeGenVTables to ASTContext, because mangling now depends on vtable layout. I also hoisted the inheritance model helpers up to be inline static methods of MSInheritanceAttr. This makes the AST code that deals with member pointers much more readable. MSVC doesn't appear to have stable manglings of null member pointers: - Null data memptrs in function templates have a mangling collision with the first field of a non-polymorphic single inheritance class. - The mangling of null data memptrs changes if you add casts. - Large null function memptrs in class templates crash MSVC. Clang uses the class template mangling for null data memptrs and the function template mangling for null function memptrs to deal with this. Reviewers: majnemer Differential Revision: http://llvm-reviews.chandlerc.com/D2695 llvm-svn: 200857
* Eliminate the ItaniumVTableContext object from CodeGenVTablesReid Kleckner2013-12-201-6/+6
| | | | | | | | | | | | | Now CodeGenVTables has only one VTableContext object, which is either Itanium or Microsoft. Fixes a FIXME with no functionality change intended. Ideally we could avoid the downcasts by pushing the things that reference the Itanium vtable context into ItaniumCXXABI.cpp, but we're not there yet. llvm-svn: 197845
* Fix vbtable indices when a class shares the vbptr with a non-virtual baseTimur Iskhodzhanov2013-11-051-6/+8
| | | | llvm-svn: 194082
* Code cleanup: rename VTableContext to ItaniumVTableContext, VTableBuilder to ↵Timur Iskhodzhanov2013-10-091-2/+2
| | | | | | ItaniumVTableBuilder and clang-format code around llvm-svn: 192288
* Reland 192220 "Abstract out parts of thunk emission code, add support for ↵Timur Iskhodzhanov2013-10-091-9/+6
| | | | | | simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
* Revert 192220 as it fails on an assertionTimur Iskhodzhanov2013-10-081-6/+9
| | | | llvm-svn: 192225
* Abstract out parts of thunk emission code, add support for simple thunks ↵Timur Iskhodzhanov2013-10-081-9/+6
| | | | | | | | when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1787 llvm-svn: 192220
* Abstract out the emission of vtables, add basic support for vtable emission ↵Timur Iskhodzhanov2013-09-271-12/+1
| | | | | | | | when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1532 llvm-svn: 191523
* Abstract out virtual calls and virtual function prologue code generation; ↵Timur Iskhodzhanov2013-08-211-0/+4
| | | | | | implement them for -cxx-abi microsoft llvm-svn: 188870
* Add MicrosoftVFTableContext to ASTTimur Iskhodzhanov2013-07-301-0/+1
| | | | llvm-svn: 187409
* [ms-cxxabi] Move CodeGenVTables::needsVTTParameter to ItaniumCXXABI.Peter Collingbourne2013-06-281-5/+0
| | | | | | | | | This function only makes sense there. Eventually it should no longer be part of the CGCXXABI interface, as it is an Itanium-specific detail. Differential Revision: http://llvm-reviews.chandlerc.com/D821 llvm-svn: 185213
* The standard ARM C++ ABI dictates that inline functions areJohn McCall2013-01-251-11/+7
| | | | | | | | never key functions. We did not implement that rule for the iOS ABI, which was driven by what was implemented in gcc-4.2. However, implement it now for other ARM-based platforms. llvm-svn: 173515
* Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate toChandler Carruth2013-01-021-1/+1
| | | | | | | | reflect the migration in r171366. Re-sort the #include lines to reflect the new paths. llvm-svn: 171369
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-3/+3
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. ↵Sylvestre Ledru2012-09-271-1/+1
| | | | | | See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766 llvm-svn: 164769
* Fix a typo 'iff' => 'if'Sylvestre Ledru2012-09-271-1/+1
| | | | llvm-svn: 164766
* Move VTable builder to ASTPeter Collingbourne2011-09-261-327/+1
| | | | llvm-svn: 140510
* Have CodeGenVTables::GenerateConstructionVTable use VTableLayoutPeter Collingbourne2011-09-261-0/+4
| | | | llvm-svn: 140509
* Implement VTableContext::createConstructionVTableLayoutPeter Collingbourne2011-09-261-0/+6
| | | | llvm-svn: 140507
* Move all vtable layout data into new VTableLayout classPeter Collingbourne2011-09-261-53/+76
| | | | llvm-svn: 140506
* Move VTableComponent to header filePeter Collingbourne2011-09-261-0/+167
| | | | llvm-svn: 140505
* Move vtable component accessors to VTableContextPeter Collingbourne2011-09-261-52/+85
| | | | llvm-svn: 140504
* Remove CodeGenVTables::ComputeVTableRelatedInformation dependency on CodeGenPeter Collingbourne2011-09-261-9/+5
| | | | llvm-svn: 140503
* Create a VTableContext class and start moving CodeGenVTables methods to itPeter Collingbourne2011-09-261-27/+40
| | | | llvm-svn: 140502
* Move BaseSubobject class to ASTPeter Collingbourne2011-09-261-66/+1
| | | | llvm-svn: 140500
* Make the VTTBuilder class independent of LLVM corePeter Collingbourne2011-09-261-0/+1
| | | | llvm-svn: 140498
* now that we have a centralized place to do so, add some using declarations forChris Lattner2011-07-201-2/+2
| | | | | | | some common llvm types: stringref and smallvector. This cleans up the codebase quite a bit. llvm-svn: 135576
* Move GlobalDecl to ASTPeter Collingbourne2011-06-141-1/+1
| | | | llvm-svn: 132973
* [Reapply r128776, modified so that it does not break debug info.]Ken Dyck2011-04-071-3/+3
| | | | | | | Change the return type of CodeGenVTables::getVirtualBaseOffsetOffset() to CharUnits. No change in functionality intended. llvm-svn: 129072
* [Reapply r128773. This is not the source of the issues Devang was seeingKen Dyck2011-04-071-2/+2
| | | | | | | | | with debug info.] Use CharUnits for the offsets in the VirtualBaseClassOffsetOffsetsMapTy. No change in functionality intended. llvm-svn: 129048
* Revert r128770, r128771, r128773 and r128776 for now. It breaks debug info.Devang Patel2011-04-041-5/+5
| | | | llvm-svn: 128842
* Change the return type of CodeGenVTables::getVirtualBaseOffsetOffset() toKen Dyck2011-04-021-3/+3
| | | | | | CharUnits. No change in functionality intended. llvm-svn: 128776
* Use CharUnits for the offsets in the VirtualBaseClassOffsetOffsetsMapTy. NoKen Dyck2011-04-021-2/+2
| | | | | | change in functionality intended. llvm-svn: 128773
* We were emitting construction v-tables with internal linkage all the time.John McCall2011-03-271-1/+2
| | | | | | | | | | | | | | | Emit them instead with the linkage of the VTT. I'm actually really ambivalent about this; it's what GCC does, but outside of improving code size (if the linkage is coalescing), I'm not sure it's at all relevant. Construction vtables are naturally referenced only by the VTT, which is itself only referenced by complete-object constructors and destructors; giving the construction vtables possibly-external linkage is important if you have an optimization that drills through the VTT to a reference to a particular construction vtable which it cannot just emit itself. llvm-svn: 128374
* Convert the BaseOffset member of BaseSubobject to CharUnits from bits. NoKen Dyck2011-03-241-6/+7
| | | | | | change in functionality intended. llvm-svn: 128190
* When building with optimizations, emit thunks with available_externally ↵Anders Carlsson2011-02-061-2/+9
| | | | | | linkage so devirtualized function calls can also be de-thunked. llvm-svn: 124984
* Make emitting a VTT a two-step process, much like emitting a VTable. You ↵Anders Carlsson2011-01-291-6/+9
| | | | | | first get the address of the VTT, and then pass it to EmitVTTDefinition. llvm-svn: 124539
* Move name mangling support from CodeGen to AST. In thePeter Collingbourne2011-01-131-88/+1
| | | | | | | | | | | | | | process, perform a number of refactorings: - Move MiscNameMangler member functions to MangleContext - Remove GlobalDecl dependency from MangleContext - Make MangleContext abstract and move Itanium/Microsoft functionality to their own classes/files - Implement ASTContext::createMangleContext and have CodeGen use it No (intended) functionality change. llvm-svn: 123386
* Make sure the VTables for template instantiations are emitted even if the ↵Argyrios Kyrtzidis2010-10-111-8/+3
| | | | | | key function doesn't have a body. llvm-svn: 116186
* Introduce Decl::hasBody() and FunctionDecl::hasBody() and use them instead ↵Argyrios Kyrtzidis2010-07-071-1/+1
| | | | | | | | of getBody() when we are just checking the existence of a body, to avoid de-serialization of the body from PCH. Makes de-serialization of the function body even more "lazier". llvm-svn: 107768
* Don't try to emit the vtable for a class just because we're emitting aJohn McCall2010-06-021-5/+10
| | | | | | | | virtual function from it. Fixes PR7241. llvm-svn: 105345
* Rework when and how vtables are emitted, by tracking where vtables areDouglas Gregor2010-05-131-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* Store the entire base subobject in SubVTTIndices.Anders Carlsson2010-05-031-6/+4
| | | | llvm-svn: 102890
* Have getSubVTTIndex take a BaseSubobject instead of just a base.Anders Carlsson2010-05-021-1/+1
| | | | llvm-svn: 102885
* If a method is virtual and the class key function is in another file, emit ↵Rafael Espindola2010-04-191-0/+9
| | | | | | | | the method as available_externally. Fixes PR6747 llvm-svn: 101757
* Vtable -> VTable renames across the board.Anders Carlsson2010-04-171-8/+8
| | | | llvm-svn: 101666
OpenPOWER on IntegriCloud