summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/ItaniumCXXABI.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Devirtualize EHScopeStack::Cleanup's dtor because it's never destroyed ↵David Blaikie2015-08-181-2/+2
| | | | | | polymorphically llvm-svn: 245378
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Justin Bogner2015-08-181-58/+32
| | | | | | | | | | | Bootstrap bots were failing: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/6382/ http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/2969 This reverts r245264. llvm-svn: 245267
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-08-181-32/+58
| | | | | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html Edit: Fixed version because of PR24479. http://reviews.llvm.org/D11859 llvm-svn: 245264
* Revert r245257 "Generating assumption loads of vptr after ctor call"Hans Wennborg2015-08-181-58/+32
| | | | | | It caused PR24479 llvm-svn: 245260
* Generating assumption loads of vptr after ctor callPiotr Padlewski2015-08-171-32/+58
| | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D11859 llvm-svn: 245257
* Remove and forbid raw_svector_ostream::flush() calls.Yaron Keren2015-08-131-7/+0
| | | | | | | | | | After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as the stream and its SmallString are always in sync. Thanks to David Blaikie for reviewing. llvm-svn: 244928
* [ItaniumCXXABI] Don't import RTTI data for classes with key functionsDavid Majnemer2015-08-061-4/+14
| | | | | | | | | MinGW has some pretty strange behvaior around RTTI and dllimport/dllexport: - RTTI data is never imported - RTTI data is only exported if the class has no key function. llvm-svn: 244266
* Rangify for loops, NFC.Yaron Keren2015-08-011-3/+3
| | | | llvm-svn: 243841
* In case of an existing GlobalVariable, the comdat is created using the name ↵Yaron Keren2015-07-291-3/+3
| | | | | | | | | | | | | of the new GV (usually NAME.1) instead of the correct NAME of the old GV. Moving comdat creation after GV replacement solves this. Patch + testcase. Reviewed by Reid Kleckner. http://reviews.llvm.org/D11594 llvm-svn: 243525
* Remove unnecessary variable.Yaron Keren2015-07-291-12/+8
| | | | llvm-svn: 243517
* Getting rid of old iterator loopsPiotr Padlewski2015-07-281-7/+7
| | | | llvm-svn: 243431
* Generating available_externally vtables for outline virtual functionsPiotr Padlewski2015-07-241-0/+33
| | | | | | | | | | | | | | Generating available_externally vtables for optimizations purposes. Unfortunatelly ItaniumABI doesn't guarantee that we will be able to refer to virtual inline method by name. But when we don't have any inline virtual methods, and key function is not defined in this TU, we can generate that there will be vtable and mark it as available_externally. This is patch will help devirtualize better. Differential Revision: http://reviews.llvm.org/D11441 llvm-svn: 243090
* Rely on default zero-arg value for IRBuilder::CreateCall calls to zero-arg ↵David Blaikie2015-07-141-4/+4
| | | | | | | | functions Patch by servuswiegehtz at yahoo.de llvm-svn: 242168
* CodeGen: Do not give local-linkage functions externally available linkage, ↵Peter Collingbourne2015-07-011-1/+1
| | | | | | | | | | | | | | | | even temporarily. When an internal-linkage thunk is code gen'd, CodeGenVTables::emitThunk will first be called with ForVTable=true (which incorrectly set the thunk's linkage to available_externally under the Itanium ABI) and later with ForVTable=false (which reset it to internal). Because we will always see a call with ForVTable=false, this incorrect linkage never ended up in the final IR. However, the temporary presence of this linkage caused us to give such functions a comdat as a result of code introduced in r241102. To avoid this, check that the thunk is externally visible before giving it available_externally linkage. llvm-svn: 241136
* [CodeGen] Rename EmitMemberPointer to EmitMemberFunctionPointerDavid Majnemer2015-06-231-2/+3
| | | | llvm-svn: 240382
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-4/+4
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-4/+4
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne2015-06-191-4/+8
| | | | | | | | | | | | | | | | | This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
* API update for streamlining of IRBuilder::CreateCall to just use ↵David Blaikie2015-05-181-4/+4
| | | | | | ArrayRef/initializer_list+braced init llvm-svn: 237625
* Revert r236879, "Do not emit thunks with available_externally linkage in ↵NAKAMURA Takumi2015-05-091-5/+8
| | | | | | | | comdats" It broke pecoff, at least i686-cygwin. llvm-svn: 236937
* Do not emit thunks with available_externally linkage in comdatsDerek Schuff2015-05-081-8/+5
| | | | | | | | | | | | | | Functions with available_externally linkage will not be emitted to object files (they will just be undefined symbols), so it does not make sense to put them in comdats. Creates a second overload of maybeSetTrivialComdat that uses the GlobalObject instead of the Decl, and uses that in several places that had the faulty logic. Differential Revision: http://reviews.llvm.org/D9580 llvm-svn: 236879
* [opaque pointer type] update for LLVM API changeDavid Blaikie2015-04-291-2/+2
| | | | llvm-svn: 236161
* Replace getPointeeType()->isFunctionType with isMemberDataPointerTypeDavid Majnemer2015-04-241-1/+1
| | | | llvm-svn: 235682
* [opaque pointer type] more GEP API migrationsDavid Blaikie2015-04-041-1/+1
| | | | llvm-svn: 234097
* [opaque pointer type] Update for GEP API changes in LLVMDavid Blaikie2015-04-021-3/+5
| | | | | | | | | | Now the GEP constant utility functions require the type to be explicitly passed (since eventually the pointer type will be opaque and not convey the required type information). For now callers can still pass nullptr (though none were needed here in Clang, which is nice) if convenienc/necessary, but eventually that will be disallowed as well. llvm-svn: 233937
* Implement CFI type checks for non-virtual calls.Peter Collingbourne2015-04-021-1/+2
| | | | | | | | | | | | This uses the same class metadata currently used for virtual call and cast checks. The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr flag has been renamed -fsanitize=cfi-vcall. Differential Revision: http://reviews.llvm.org/D8756 llvm-svn: 233874
* [MS ABI] Rework .xdata HandlerType emissionDavid Majnemer2015-03-291-1/+2
| | | | | | | | | | Utilizing IMAGEREL relocations for synthetic IR constructs isn't valuable, just clutter. While we are here, simplify HandlerType names by making the numeric value for the 'adjective' part of the mangled name instead of appending '.const', etc. The old scheme made for very long global names and leads to wordy things like '.std_bad_alloc' llvm-svn: 233503
* MS ABI: Fix a couple of -Winconsistent-missing-override warningsJustin Bogner2015-03-171-2/+2
| | | | llvm-svn: 232559
* MS ABI: Emit HandlerMap entries for C++ catchDavid Majnemer2015-03-171-1/+2
| | | | | | | | | | | | | The HandlerMap describes, to the runtime, what sort of catches surround the try. In principle, this structure has to be emitted by the backend because only it knows the layout of the stack (the runtime needs to know where on the stack the destination of a copy lives, etc.) but there is some C++ specific information that the backend can't reason about. Stick this information in special LLVM globals with the relevant "const", "volatile", "reference" info mangled into the name. llvm-svn: 232538
* WIPDavid Majnemer2015-03-171-3/+5
| | | | llvm-svn: 232537
* MS ABI: Don't use qualified pointee types for 'catch' EH TypeDescriptorsDavid Majnemer2015-03-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Qualifiers are located next to the TypeDescriptor in order to properly ensure that a pointer type can only be caught by a more qualified catch handler. This means that a catch handler of type 'const int *' requires an RTTI object for 'int *'. We got this correct for 'throw' but not for 'catch'. N.B. We don't currently have the means to store the qualifiers because LLVM's EH strategy is tailored to the Itanium scheme. The Itanium ABI stores qualifiers inside the type descriptor in such a way that the manner of qualification is stored in addition to the pointee type's descriptor. Perhaps the best way of modeling this for the MS ABI is using an aggregate type to bundle the qualifiers with the descriptor? This is tricky because we want to make it clear to the optimization passes which catch handlers invalidate other handlers. My current thoughts on a design for this is along the lines of: { { TypeDescriptor* TD, i32 QualifierFlags }, i32 MiscFlags } The idea is that the inner most aggregate is all that is needed to communicate that one catch handler might supercede another. The 'MiscFlags' field would be used to hold the bitpattern for the notion that the 'catch' handler does not need to invoke a copy-constructor because we are catching by reference. llvm-svn: 232318
* MS ABI: Implement support for throwing a C++ exceptionDavid Majnemer2015-03-051-0/+54
| | | | | | | | | | | | | | | | | | | | | | | Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
* Split catch IRgen into ItaniumCXXABI and MicrosoftCXXABIReid Kleckner2015-03-031-0/+355
| | | | | | | | | Use llvm.eh.begincatch for Microsoft-style catches. This moves lots of CGException code into ItaniumCXXABI. Sorry for the blame pain. llvm-svn: 231105
* Implement Control Flow Integrity for virtual calls.Peter Collingbourne2015-02-201-0/+4
| | | | | | | | | | | | | | | This patch introduces the -fsanitize=cfi-vptr flag, which enables a control flow integrity scheme that checks that virtual calls take place using a vptr of the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst file. It also introduces the -fsanitize=cfi flag, which is currently a synonym for -fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented in Clang. Differential Revision: http://reviews.llvm.org/D7424 llvm-svn: 230055
* Change representation of member function pointers for MIPS targetsZoran Jovanovic2015-02-181-0/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D7148 llvm-svn: 229680
* Use a trivial comdat for C++ tables.Rafael Espindola2015-01-151-2/+9
| | | | | | | | | This produces comdats for vtables, typeinfo, typeinfo names, and vtts. When combined with llvm not producing implicit comdats, not doing this would cause code bloat on ELF and link errors on COFF. llvm-svn: 226227
* Use a trivial comdat for inline ctor/dtor when not using C5/D5.Rafael Espindola2015-01-151-0/+2
| | | | | | | When combined with llvm not producing implicit comdats, not doing this would cause code bloat on ELF and link errors on COFF. llvm-svn: 226211
* [patch][pr19848] Produce explicit comdats in clang.Rafael Espindola2015-01-121-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | The llvm IR until recently had no support for comdats. This was a problem when targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of dead bits to remain on the executable (unless -ffunction-sections, -fdata-sections and --gc-sections were used). To fix the problem, llvm's codegen will just assume that any weak or linkonce that is not in an explicit comdat should be output in one with the same name as the global. This unfortunately breaks cases like pr19848 where a weak symbol is not xpected to be part of any comdat. Now that we have explicit comdats in the IR, we can finally get both cases right. This first patch just makes clang give explicit comdats to GlobalValues where t is allowed to. A followup patch to llvm will then stop implicitly producing comdats. llvm-svn: 225705
* Fix comment typo.Nico Weber2015-01-071-1/+1
| | | | llvm-svn: 225340
* Revert "Put static local variables of inline functions in the function comdat."Rafael Espindola2014-12-171-4/+2
| | | | | | | | | This reverts commit r224369. Thanks to Reid Kleckner for pointing out that we need a bigger gun to fix this case. llvm-svn: 224475
* Put static local variables of inline functions in the function comdat.Rafael Espindola2014-12-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | The variable (and the GV) is only ever used if the function is. Putting it in the function's comdat make it easier for the linker to discard them. The motivating example is struct S { static const int x; }; // const int S::x = 42; inline const int *f() { static const int y = S::x; return &y; } const int *g() { return f(); } With S::x commented out, _ZZ1fvE1y is a variable with a guard variable that is initialized by f. With S::x present, _ZZ1fvE1y is a constant. llvm-svn: 224369
* Use nullptr to silence -Wsentinel when self-hosting on WindowsReid Kleckner2014-12-011-1/+1
| | | | | | | | | | | Richard rejected my Sema change to interpret an integer literal zero in a varargs context as a null pointer, so -Wsentinel sees an integer literal zero and fires off a warning. Only CodeGen currently knows that it promotes integer literal zeroes in this context to pointer size on Windows. I didn't want to teach -Wsentinel about that compatibility hack. Therefore, I'm migrating to C++11 nullptr. llvm-svn: 223079
* MS ABI: Add CodeGen support for rethrowing MS C++ exceptionsDavid Majnemer2014-11-251-0/+16
| | | | | | | | | | Rethrowing exceptions in the MS model is very simple: just call _CxxThrowException with nullptr for both arguments. N.B. They chose stdcall as the calling convention for x86 but cdecl for all other platforms. llvm-svn: 222733
* Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie2014-11-191-2/+2
| | | | | | pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-071-2/+2
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* CodeGen, Itanium: Properly dllimport RTTI dataDavid Majnemer2014-11-071-1/+10
| | | | | | | | | | We would blindly assume that RTTI data should have the same linkage as the vtable because we didn't think the RTTI data was external. This oversight stemmed because we didn't take dllimport into account. This fixes PR21512. llvm-svn: 221511
* CodeGen: Declutter the emitVirtualObjectDelete interfaceDavid Majnemer2014-11-011-7/+9
| | | | | | No functionality change intended. llvm-svn: 221043
* MS ABI: Properly call global delete when invoking virtual destructorsDavid Majnemer2014-10-311-25/+45
| | | | | | | | | | | | | | | | | | | | Summary: The Itanium ABI approach of using offset-to-top isn't possible with the MS ABI, it doesn't have that kind of information lying around. Instead, we do the following: - Call the virtual deleting destructor with the "don't delete the object flag" set. The virtual deleting destructor will return a pointer to 'this' adjusted to the most derived class. - Call the global delete using the adjusted 'this' pointer. Reviewers: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5996 llvm-svn: 220993
* SanitizerBlacklist: blacklist functions by their source location.Alexey Samsonov2014-10-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
* MS ABI: Implement thread_local for global variablesDavid Majnemer2014-10-051-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This add support for the C++11 feature, thread_local global variables. The ABI Clang implements is an improvement of the MSVC ABI. Sadly, further improvements could be made but not without sacrificing ABI compatibility. The feature is implemented as follows: - All thread_local initialization routines are pointed to from the .CRT$XDU section. - All non-weak thread_local variables have their initialization routines call from a single function instead of getting their own .CRT$XDU section entry. This is done to open up optimization opportunities to the compiler. - All weak thread_local variables have their own .CRT$XDU section entry. This entry is in a COMDAT with the global variable it is initializing; this ensures that we will initialize the global exactly once. - Destructors are registered in the initialization function using __tlregdtor. Differential Revision: http://reviews.llvm.org/D5597 llvm-svn: 219074
OpenPOWER on IntegriCloud