summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/MicrosoftCXXABI.cpp
Commit message (Collapse)AuthorAgeFilesLines
* MS ABI: Use musttail for thunk IR generationReid Kleckner2014-05-151-2/+25
| | | | | | | | | | | This allows us to perfectly forward non-trivial arguments that use inalloca. We still can't forward non-trivial arguments through thunks when we have a covariant return type with a non-trivial adjustment. This would require emitting an extra copy, which is non-conforming anyway. llvm-svn: 208927
* Don't copy objects with trivial, deleted copy ctorsReid Kleckner2014-05-141-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This affects both the Itanium and Microsoft C++ ABIs. This is in anticipation of a change to the Itanium C++ ABI, and should match GCC's current behavior. The new text will likely be: """ Pass an object of class type by value if every copy constructor and move constructor is deleted or trivial and at least one of them is not deleted, and the destructor is trivial. """ http://sourcerytools.com/pipermail/cxx-abi-dev/2014-May/002728.html On x86 Windows, we can mostly use the same logic, where we use inalloca instead of passing by address. However, on Win64, there are register parameters, and we have to do what MSVC does. MSVC ignores the presence of non-trivial move constructors and only considers the presence of non-trivial or deleted copy constructors. If a non-trivial or deleted copy ctor is present, it passes the argument indirectly. This change fixes bugs and makes us more ABI compatible with both GCC and MSVC. Fixes PR19668. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3660 llvm-svn: 208786
* Push record return type classification into CGCXXABIReid Kleckner2014-05-131-4/+22
| | | | | | | | | | | | In the Microsoft C++ ABI, instance methods always return records indirectly via the second hidden parameter. This was implemented in X86_32ABIInfo, but not WinX86_64ABIInfo. Rather than exposing a handful of boolean methods in the CGCXXABI interface, we can expose a single method that applies C++ ABI return value classification rules. llvm-svn: 208733
* MS ABI: Pass 'sret' as the second parameter of instance methodsReid Kleckner2014-05-091-0/+2
| | | | | | | | | | | | | | | | | Summary: MSVC always passes 'sret' after 'this', unlike GCC. This required changing a number of places in Clang that assumed the sret parameter was always first in LLVM IR. This fixes win64 MSVC ABI compatibility for methods returning structs. Reviewers: rsmith, majnemer Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3618 llvm-svn: 208458
* MS ABI x64: Pass small objects with dtors but no copy ctors directlyReid Kleckner2014-05-031-11/+28
| | | | | | | | | | | | | | | Passing objects directly (in registers or memory) creates a second copy of the object in the callee. The callee always destroys its copy, but we also have to destroy any temporary created in the caller. In other words, copy elision of these kinds of objects is impossible. Objects larger than 8 bytes with non-trivial dtors and trivial copy ctors are still passed indirectly, and we can still elide copies of them. Fixes PR19640. llvm-svn: 207889
* MS ABI: Fix logic bug in member pointer null test codeReid Kleckner2014-05-021-1/+1
| | | | | | | | | This code is trying to test if the pointer is *not* null. Therefore we should use 'or' instead of 'and' to combine the results of 'icmp ne'. This logic is consistent with the general member pointer comparison code in EmitMemberPointerComparison. llvm-svn: 207815
* MS ABI: Use a different guard variable for each weak globalReid Kleckner2014-04-231-11/+16
| | | | | | | | | | We were using the same guard variable and failing to initialize the second global. Clang is still not MS ABI compatible in this area. Fixing that is PR16959, which will require LLVM changes to @llvm.global_ctors. llvm-svn: 207008
* Fix PR19104: Incorrect handling of non-virtual calls of virtual methodsTimur Iskhodzhanov2014-03-141-87/+73
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D3054 llvm-svn: 203949
* [C++11] Replacing CXXRecordDecl iterators vbases_begin() and vbases_end() ↵Aaron Ballman2014-03-131-4/+2
| | | | | | with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203808
* [C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with ↵Aaron Ballman2014-03-131-3/+2
| | | | | | iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-121-69/+74
| | | | | | class. llvm-svn: 203643
* [-cxx-abi microsoft] Implement local manglings accuratelyDavid Majnemer2014-03-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-021-2/+3
| | | | llvm-svn: 202639
* MS ABI: Fix vftable mangling by using the vbtable name algorithmReid Kleckner2014-02-271-27/+25
| | | | | | | | | | | | | | | | | | Summary: This merges VFPtrInfo and VBTableInfo into VPtrInfo, since they hold almost the same information. With that change, the vbtable mangling code can easily be applied to vftable data and we magically get the correct, unambiguous vftable names. Fixes PR17748. Reviewers: timurrrr, majnemer CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2893 llvm-svn: 202425
* MS ABI: Include the vfptr offset in memptrs to virtual methodsReid Kleckner2014-02-211-13/+22
| | | | | | | | | | | | | | | Virtual methods expect 'this' to point to the vfptr containing the virtual method, and this extends to virtual member pointer thunks. The relevant vfptr is always at offset zero on entry to the thunk, and no this adjustment is needed. Previously we would not include the vfptr adjustment in the member pointer, and we'd look at the vfptr offset when loading from the vftable in the thunk. Fixes PR18917. llvm-svn: 201835
* Sema: Do not assert when dereferencing member pointer using virtual ↵David Majnemer2014-02-201-27/+27
| | | | | | | | | | | | | | inheritance with an incomplete class type The MS ABI requires that we determine the vbptr offset if have a virtual inheritance model. Instead, raise an error pointing to the diagnostic when this happens. This fixes PR18583. Differential Revision: http://llvm-reviews.chandlerc.com/D2842 llvm-svn: 201824
* MS ABI: Remove nv adjustment from direct vdtor calls and prologuesReid Kleckner2014-02-181-0/+15
| | | | | | | | | | | | | | | | | | | | Summary: Generally the vector deleting dtor, which we model as a vtable thunk, takes care of non-virtual adjustment and delegates to the other destructor variants. The other non-complete destructor variants assume that 'this' on entry points to the virtual base subobject that first declared the virtual destructor. We need to change the adjustment in both the prologue and the vdtor call setup. Reviewers: timurrrr CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2821 llvm-svn: 201612
* Remove the -fhidden-weak-vtables -cc1 option. It was dead,John McCall2014-02-081-2/+2
| | | | | | gross, and increasingly replaced through other mechanisms. llvm-svn: 201011
* Remove unused variable to fix -Werror buildReid Kleckner2014-02-051-3/+0
| | | | llvm-svn: 200861
* MS ABI: Mangle member pointer template argumentsReid Kleckner2014-02-051-77/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ms-cxxabi] Use inalloca on win32 when passing non-trivial C++ objectsReid Kleckner2014-02-011-2/+8
| | | | | | | | | | | | | | | | | | | When a non-trivial parameter is present, clang now gathers up all the parameters that lack inreg and puts them into a packed struct. MSVC always aligns each parameter to 4 bytes and no more, so this is a pretty simple struct to lay out. On win64, non-trivial records are passed indirectly. Prior to this change, clang was incorrectly using byval on win64. I'm able to self-host a working clang with this change and additional LLVM patches. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D2636 llvm-svn: 200597
* Revert "Revert r199416, "MS ABI: Improve selection of an inheritance model""David Majnemer2014-01-171-39/+50
| | | | | | | | | | This reverts commit r199475 (which reverted r199416) with fixes for the breakages. We wouldn't lock an inheritance model if we saw a pointer-to-member formed as a result of the address-of operator. llvm-svn: 199482
* Revert r199416, "MS ABI: Improve selection of an inheritance model"NAKAMURA Takumi2014-01-171-50/+39
| | | | | | | | | | | | It broke tests for targeting x86_64-pc-win32: Clang Tools :: clang-modernize/LoopConvert/array.cpp Clang :: CodeGenCXX/2010-05-10-Var-DbgInfo.cpp Clang :: CodeGenCXX/member-call-parens.cpp Clang :: CodeGenCXX/ptr-to-datamember.cpp Clang :: SemaTemplate/instantiate-function-1.cpp llvm-svn: 199475
* MS ABI: Improve selection of an inheritance modelDavid Majnemer2014-01-161-39/+50
| | | | | | | | | | | | | | | | | | | | | | | | The MSVC ABI is rather finicky about the exact representation of it's pointer-to-member representation. The exact position of when and where it will go with one representation versus another appears to be when it desires the pointer-to-member to be complete. To properly implement this in clang, do several things: - Give up on tracking the polymorphic nature of the class. It isn't useful to Sema and is only pertinent when choosing CodeGen-time details like whether the field-offset can be 0 instead of -1. - Insist on locking-in the inheritance model when we ask our pointer-to-member type to be complete. From there, grab the underlying CXXRecordDecl and try to make *that* complete. Once we've done this, we can calculate it's inheritance model and apply it using an attribute. N.B. My first bullet point is a lie. We will eventually care about the specifics of whether or not a CXXRecordDecl is or is not polymorphic because MSVC compatible mangling of such things depends on it. However, I believe we will handle this in a rather different way. llvm-svn: 199416
* [ms-abi] Remove duplicated vbptr offset codeReid Kleckner2014-01-141-39/+5
| | | | | | | | | Record layout will tell us the offset of a shared vbptr inside a non-virtual base. No functionality change. llvm-svn: 199171
* Sort all the #include lines with LLVM's utils/sort_includes.py whichChandler Carruth2014-01-071-1/+1
| | | | | | | encodes the canonical rules for LLVM's style. I noticed this had drifted quite a bit when cleaning up LLVM, so wanted to clean up Clang as well. llvm-svn: 198686
* [ms-cxxabi] Improve vbtable name mangling accuracyReid Kleckner2014-01-031-11/+20
| | | | | | | | | | | | | | | | | | | | | | Summary: This makes us more compatible with MSVC 2012+ and fixes PR17748 where we would give two tables the same name. Rather than doing a fresh depth-first traversal of the inheritance graph for every record's vbtables, now we memoize vbtable paths for each record. By doing memoization, we end up considering virtual bases of subobjects that come later in the depth-first traversal. Where previously we would have ignored a virtual base that we'd already seen, we now consider it for name mangling purposes without emitting a duplicate vbtable for it. Reviewers: majnemer CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2509 llvm-svn: 198462
* Remove unused variable to fix clang warningReid Kleckner2014-01-031-1/+0
| | | | llvm-svn: 198382
* [ms-cxxabi] Move VBTableBuilder from CodeGen over to AST/VTableBuilder.cppReid Kleckner2014-01-031-27/+118
| | | | | | | | | | | | | | | | | | | | | Summary: No functionality change. This code should live here long-term because we should be able to use it to compute correct vftable names. It turns out that the most natural way to implement the naming algorithm is to use a caching layer similar to what we already have for virtual table info in VTableContext. Subsequent changes will take advantage of this to fix PR17748, where we have a vbtable name collision. Reviewers: majnemer CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2499 llvm-svn: 198380
* [ms-cxxabi] The 'most derived' ctor parameter usually comes lastReid Kleckner2013-12-171-39/+47
| | | | | | | | | | | | | | Unlike Itanium's VTTs, the 'most derived' boolean or bitfield is the last parameter for non-variadic constructors, rather than the second. For variadic constructors, the 'most derived' parameter comes after the 'this' parameter. This affects constructor calls and constructor decls in a variety of places. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D2405 llvm-svn: 197518
* Move C++ destructor emission into CGCXXABIReid Kleckner2013-12-131-0/+18
| | | | | | | No functionality change. Only Itanium C++ destructors have implicit VTT parameters. llvm-svn: 197194
* [-cxx-abi microsoft] Mangle large integral constants correctlyDavid Majnemer2013-12-091-3/+3
| | | | | | | | | | | | | | | | | | | Testing has revealed that large integral constants (i.e. > INT64_MAX) are always mangled as-if they are negative, even in places where it would not make sense for them to be negative (like non-type template parameters of type unsigned long long). To address this, we change the way we model number mangling: always mangle as-if our number is an int64_t. This should result in correct results when we have large unsigned numbers. N.B. Bizarrely, things that are 32-bit displacements like vbptr offsets are mangled as-if they are unsigned 32-bit numbers. This is a pretty egregious waste of space, it would be a 4x savings if we could mangle it like a signed 32-bit number. Instead, we explicitly cast these displacements to uint32_t and let the mangler proceed. llvm-svn: 196771
* [ms-cxxabi] bitcast to i8* to deref a data member pointerReid Kleckner2013-12-051-0/+5
| | | | | | | | This was causing us to miscompile llvm::SymbolTableListTraits::getListOwner(), which uses data member pointers. llvm-svn: 196545
* Fix a tranche of comment, test and doc typosAlp Toker2013-12-051-1/+1
| | | | llvm-svn: 196510
* [-cxx-abi microsoft] Emit linkonce_odr definitions for declarations of ↵Hans Wennborg2013-11-211-0/+2
| | | | | | | | | | | | | | | static data members with inline initializers (PR17689) This makes Clang emit a linkonce_odr definition for 'val' in the code below, to be compatible with MSVC-compiled code: struct Foo { static const int val = 1; }; Differential Revision: http://llvm-reviews.chandlerc.com/D2233 llvm-svn: 195283
* Remove an unused local from r194827Alp Toker2013-11-151-1/+0
| | | | llvm-svn: 194835
* [-cxx-abi microsoft] Emit thunks for pointers to virtual member functionsHans Wennborg2013-11-151-7/+69
| | | | | | | | | | | | | | | | Instead of storing the vtable offset directly in the function pointer and doing a branch to check for virtualness at each call site, the MS ABI generates a thunk for calling the function at a specific vtable offset, and puts that in the function pointer. This patch adds support for emitting such thunks. However, it doesn't support pointers to virtual member functions that are variadic, have an incomplete aggregate return type or parameter, or are overriding a function in a virtual base class. Differential Revision: http://llvm-reviews.chandlerc.com/D2104 llvm-svn: 194827
* No need to use CGM.getCXXABI() from CXXABITimur Iskhodzhanov2013-11-131-4/+4
| | | | llvm-svn: 194584
* Minor refinement of VTableBuilder.h: fix wrong indentation, rename a struct ↵Timur Iskhodzhanov2013-11-071-3/+3
| | | | | | field with a more appropriate name llvm-svn: 194202
* Fix PR17738 - add support for vtordisp thunks when using -cxx-abi microsoftTimur Iskhodzhanov2013-11-061-2/+23
| | | | llvm-svn: 194132
* Fix vbtable indices when a class shares the vbptr with a non-virtual baseTimur Iskhodzhanov2013-11-051-16/+18
| | | | llvm-svn: 194082
* Make thunk this/return adjustment ABI-specific. Also, fix the return ↵Timur Iskhodzhanov2013-10-301-0/+64
| | | | | | | | adjustment when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D2026 llvm-svn: 193679
* Fix the inconsistent order of parameters in the GetVBaseOffsetFromVBPtr ↵Timur Iskhodzhanov2013-10-271-3/+3
| | | | | | definition and declaration llvm-svn: 193505
* Use GEPs correctly when adjusting this in MicrosoftCXXABITimur Iskhodzhanov2013-10-221-3/+12
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D1977 llvm-svn: 193176
* [ms-cxxabi] Error out on virtual function memptrsReid Kleckner2013-10-171-0/+1
| | | | | | These are uncommon and this is better than miscompiling. llvm-svn: 192923
* Follow-up to r192822: fix Clang assertion when building with -fexceptionsTimur Iskhodzhanov2013-10-171-6/+13
| | | | llvm-svn: 192875
* [-cxx-abi microsoft] Fix this argument/parameter offsets for virtual ↵Timur Iskhodzhanov2013-10-161-14/+69
| | | | | | | | destructors in the presence of virtual bases Reviewed at http://llvm-reviews.chandlerc.com/D1939 llvm-svn: 192822
* [ms-cxxabi] Fix assert in unspecified inheritance memptr emissionReid Kleckner2013-10-151-2/+4
| | | | | | | | | If a class is using the unspecified inheritance model for member pointers and later we find the class is defined to use single inheritance, zero out the vbptr offset field of the member pointer when it is formed. llvm-svn: 192664
* Initialize vtorDisp in class constructors and destructorsTimur Iskhodzhanov2013-10-091-0/+58
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D1867 llvm-svn: 192312
* Reland 192220 "Abstract out parts of thunk emission code, add support for ↵Timur Iskhodzhanov2013-10-091-0/+12
| | | | | | simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
OpenPOWER on IntegriCloud