summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Introduce a type-safe enum for ForDefinition.John McCall2016-11-301-2/+3
| | | | llvm-svn: 288289
* Refactor call emission to package the function pointer together withJohn McCall2016-10-261-21/+18
| | | | | | | | | | | abstract information about the callee. NFC. The goal here is to make it easier to recognize indirect calls and trigger additional logic in certain cases. That logic will come in a later patch; in the meantime, I felt that this was a significant improvement to the code. llvm-svn: 285258
* Alias must point to a definitionAditya Kumar2016-10-021-8/+6
| | | | | | | | | | | | | | | Reapplying the patch after modifying the test case. Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend. https://llvm.org/bugs/show_bug.cgi?id=30341 This patch disables alias to available_externally definitions. Reviewers: eugenis, rsmith Differential Revision: https://reviews.llvm.org/D24682 llvm-svn: 283063
* Revert "[PR30341] Alias must point to a definition"Aditya Kumar2016-09-291-6/+8
| | | | | | | | This reverts commit r282679. Ninja check fails, reverting to debug the issue. llvm-svn: 282710
* [PR30341] Alias must point to a definitionAditya Kumar2016-09-291-8/+6
| | | | | | | | | | | | | Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend. https://llvm.org/bugs/show_bug.cgi?id=30341 This patch disables alias to available_externally definitions. Reviewers: eugenis, rsmith Differential Revision: https://reviews.llvm.org/D24682 llvm-svn: 282679
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-1/+1
| | | | | | | | | | | Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
* Basic: move CodeGenOptions from FrontendSaleem Abdulrasool2016-04-071-1/+1
| | | | | | | | This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This fixes the layering violation introduced earlier by threading CodeGenOptions into TargetInfo. It should also fix the modules based self-hosting builds. NFC. llvm-svn: 265702
* Use CodeGenModule::addReplacement() instead of directly accessing ↵Yaron Keren2016-02-071-1/+1
| | | | | | | | Replacements[]. This helps when trying to debug who inserted into Replacements. llvm-svn: 260028
* [COFF] Don't try to emit weak aliases on COFFReid Kleckner2015-11-101-5/+10
| | | | | | | | | | | | | | | | | This comes up when a derived class destructor is equivalent to a base class destructor defined in the same TU, and we try to alias them. A COFF weak alias cannot satisfy a normal undefined symbol reference from another TU. The other TU must also mark the referenced symbol as weak, and we can't rely on that. Clang already has a special case here for dllexport, but we failed to realize that the problem also applies to other non-discardable symbols such as those from explicit template instantiations. Fixes PR25477. llvm-svn: 252659
* Revert "Always_inline codegen rewrite" and 2 follow-ups.Evgeniy Stepanov2015-09-141-4/+8
| | | | | | | | | | Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs" Revert "Always_inline codegen rewrite." Reason for revert: PR24793. llvm-svn: 247620
* [opaque pointer type] Fix a few uses of PointerType::getElementType in favor ↵David Blaikie2015-09-141-4/+4
| | | | | | | | | | of uses of types already available elsewhere These are a few cleanups I happened to have from trying to go in a different direction recently, so just flushing them out while I have them. llvm-svn: 247593
* Revert "[opaque pointer type] update for LLVM API change"David Blaikie2015-09-141-2/+2
| | | | | | | | | | This was the wrong direction to take anyway (because ultimately the GlobalValue needed the pointee type again and /it/ used PointerType::getElementType eventually anyway)... let's go a different way. This reverts commit r236161. llvm-svn: 247586
* Always_inline codegen rewrite.Evgeniy Stepanov2015-09-121-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code. Libc++ relies on the compiler never emitting such undefined reference. With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F. The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases). This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference. This patch is based on ideas by Chandler Carruth and Richard Smith. llvm-svn: 247494
* Revert "Specify target triple in alwaysinline tests."Evgeniy Stepanov2015-09-111-4/+8
| | | | | | | | | Revert "Always_inline codegen rewrite." Breaks gdb & lldb tests. Breaks on Fedora 22 x86_64. llvm-svn: 247491
* Always_inline codegen rewrite.Evgeniy Stepanov2015-09-111-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code. Libc++ relies on the compiler never emitting such undefined reference. With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F. The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases). This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference. This patch is based on ideas by Chandler Carruth and Richard Smith. llvm-svn: 247465
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
* Refactored dtor sanitizing into EHScopeStackNaomi Musgrave2015-09-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Dtor sanitization handled amidst other dtor cleanups, between cleaning bases and fields. Sanitizer call pushed onto stack of cleanup operations. Reviewers: eugenis, kcc Differential Revision: http://reviews.llvm.org/D12022 Refactoring dtor sanitizing emission order. - Support multiple inheritance by poisoning after member destructors are invoked, and before base class destructors are invoked. - Poison for virtual destructor and virtual bases. - Repress dtor aliasing when sanitizing in dtor. - CFE test for dtor aliasing, and repression of aliasing in dtor code generation. - Poison members on field-by-field basis, with collective poisoning of trivial members when possible. - Check msan flags and existence of fields, before dtor sanitizing, and when determining if aliasing is allowed. - Testing sanitizing bit fields. llvm-svn: 246815
* PR17829: Proper diagnostic of mangled names conflictsAndrey Bokhanko2015-08-311-10/+7
| | | | | | | | | | Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
* Get the dll storage class right for structors of classes exported/imported ↵Hans Wennborg2015-05-281-0/+2
| | | | | | | | | via explicit instantiation (PR23667) This is a follow-up to r238266. It turned out structors are codegened through a different path, and didn't get the storage class set in EmitGlobalFunctionDefinition. llvm-svn: 238443
* CGCXX: Use cast in getAddrOfCXXStructor()Duncan P. N. Exon Smith2015-05-061-2/+1
| | | | | | | | All callers should be passing `CXXConstructorDecl` or `CXXDestructorDecl` here, so use `cast<>` instead of `dyn_cast<>` when setting up the `GlobalDecl`. llvm-svn: 236651
* [opaque pointer type] update for LLVM API changeDavid Blaikie2015-04-291-2/+2
| | | | llvm-svn: 236161
* Don't use a doc comment in a function body.Nico Weber2015-01-121-3/+3
| | | | llvm-svn: 225701
* ignore -mconstructor-aliases when adding field paddings for asanKostya Serebryany2014-10-311-0/+5
| | | | | | | | | | | | | | | | | | Summary: When we are adding field paddings for asan even an empty dtor has to remain in the code, so we ignore -mconstructor-aliases if the paddings are going to be added. Test Plan: added a test Reviewers: rsmith, rnk, rafael Reviewed By: rafael Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6038 llvm-svn: 220986
* CodeGen: Don't form weak dllexport aliasesDavid Majnemer2014-10-241-0/+5
| | | | | | | | | | | The MS linker cannot do anything interesting with these, it doesn't make sense to emit them. This fixes PR21373. Differential Revision: http://reviews.llvm.org/D5986 llvm-svn: 220595
* Allow dllexport alias to base destructors.Rafael Espindola2014-10-071-5/+1
| | | | | | | | | | | We used to avoid these, but it looks like we did so just because we were not handling dllexport alias correctly. Dario Domizioli fixed that, so allow these aliases. Based on a patch by Dario Domizioli! llvm-svn: 219206
* Reduce code duplication a bit more. NFC.Rafael Espindola2014-09-151-0/+22
| | | | llvm-svn: 217811
* Move emitCXXStructor to CGCXXABI.Rafael Espindola2014-09-151-77/+0
| | | | | | A followup patch will address the code duplication. llvm-svn: 217807
* Create a emitCXXStructor function and make the existing emitCXXConstructor andRafael Espindola2014-09-151-34/+45
| | | | | | | | emitCXXDestructor static helpers. A next patch will make it a helper in CGCXXABI. llvm-svn: 217804
* Merge GetAddrOfCXXConstructor and GetAddrOfCXXDonstructor. NFC.Rafael Espindola2014-09-111-21/+4
| | | | llvm-svn: 217598
* Handle constructors and destructors a bit more uniformly in CodeGen.Rafael Espindola2014-09-081-31/+33
| | | | | | | | | There were code paths that are duplicated for constructors and destructors just because we have both CXXCtorType and CXXDtorsTypes. This patch introduces an unified enum and reduces code deplication a bit. llvm-svn: 217383
* Update for llvm API change.Rafael Espindola2014-06-031-9/+6
| | | | | | Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
* Start adding support for dllimport/dllexport on classes (PR11170)Hans Wennborg2014-05-301-0/+4
| | | | | | | | | | | | | | | | This implements the central part of support for dllimport/dllexport on classes: allowing the attribute on class declarations, inheriting it to class members, and forcing emission of exported members. It's based on Nico Rieck's patch from http://reviews.llvm.org/D1099. This patch doesn't propagate dllexport to bases that are template specializations, which is an interesting problem. It also doesn't look at the rules when redeclaring classes with different attributes, I'd like to do that separately. Differential Revision: http://reviews.llvm.org/D3877 llvm-svn: 209908
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-3/+3
| | | | llvm-svn: 209272
* Update for llvm api change.Rafael Espindola2014-05-171-2/+2
| | | | llvm-svn: 209077
* Update for llvm api change.Rafael Espindola2014-05-171-2/+2
| | | | llvm-svn: 209074
* Update for llvm api change.Rafael Espindola2014-05-161-6/+9
| | | | | | | | | | Now that llvm cannot represent alias cycles, we have to diagnose erros just before trying to close the cycle. This degrades the errors a bit. The real solution is what it was before: if we want to provide good errors for these cases, we have to be able to find a clang level decl given a mangled name and produce the error from Sema. llvm-svn: 209008
* Update for llvm API change.Rafael Espindola2014-05-161-2/+2
| | | | llvm-svn: 208984
* Use auto to avoid duplicating the type.Rafael Espindola2014-05-091-9/+9
| | | | llvm-svn: 208374
* Cleanup setFunctionDefinitionAttributes.Rafael Espindola2014-05-081-2/+2
| | | | | | Use more specific type, update comments and name style. llvm-svn: 208328
* [C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with ↵Aaron Ballman2014-03-131-4/+3
| | | | | | iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
* [C++11] Replacing RecordDecl iterators field_begin() and field_end() with ↵Aaron Ballman2014-03-081-2/+1
| | | | | | iterator_range fields(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203355
* Don't produce an alias between destructors with different calling conventions.Rafael Espindola2014-03-051-0/+6
| | | | | | Fixes pr19007. llvm-svn: 203007
* [ms-abi] Always generate complete constructors in the Microsoft C++ ABIReid Kleckner2014-01-131-5/+7
| | | | | | | | Fixes PR18435, where we generated a base ctor instead of a complete ctor, and so failed to construct virtual bases when constructing the complete object. llvm-svn: 199160
* Avoid adding some decls to DeferredDeclsToEmit.Rafael Espindola2013-12-091-8/+12
| | | | | | | | Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
* Fix a tranche of comment, test and doc typosAlp Toker2013-12-051-4/+4
| | | | llvm-svn: 196510
* Adjust r194296 to not apply the alias replacement for externallyJoerg Sonnenberger2013-11-221-1/+8
| | | | | | | | available always-inline functions. This breaks libc++'s locale implementation. Code generation for this case should be fixed, but this is a stop gap fix for clang 3.4. llvm-svn: 195501
* Don't use alias from derived dtor to base dtor at -O0.Rafael Espindola2013-11-131-0/+5
| | | | | | | | | | This patch disables aliasing (and rauw) of derived dtors to base dtors at -O0. This optimization can have a negative impact on the debug quality. This was a latent bug for some time with local classes, but got noticed when it was generalized and broke gdb's destrprint.exp. llvm-svn: 194618
* Drop windows specific handling of equivalent destructors.Rafael Espindola2013-11-131-9/+0
| | | | | | | | | Now that the relevant tests use -mconstructor-aliases and the missing features have been implemented, we can just drop this. No functionality change. llvm-svn: 194595
* Avoid producing mismatched comdats.Rafael Espindola2013-11-121-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | The problem was that given template<typename T> struct foo { ~foo() {} }; template class foo<int>; We would produce a alias, creating a comdat with D0 and D1, since the symbols have to be weak. Another TU is not required to have a explicit template instantiation definition or an explict template instantiation declaration and for template<typename T> struct foo { ~foo() {} }; foo<int> a; we would produce a comdat with only one symbol in it. llvm-svn: 194520
* Fix pr17875.Rafael Espindola2013-11-111-3/+1
| | | | | | | | The assert this patch deletes was valid only when aliasing D2 to D1, not when looking at a base class. Since the assert was in the path where we had already decided to not produce an alias, just drop it. llvm-svn: 194411
OpenPOWER on IntegriCloud