summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/thunks.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix thunks.cpp test, don't FileCheck for anon namespace idReid Kleckner2019-09-071-1/+1
| | | | | | | The anon namespace id is a hash of the main input path to the compiler, which varies in the test suite because the input path is absolute. llvm-svn: 371277
* Use musttail for variadic method thunks when possibleReid Kleckner2019-09-061-6/+127
| | | | | | | | | | | | | | | | | | | | | This avoids cloning variadic virtual methods when the target supports musttail and the return type is not covariant. I think we never implemented this previously because it doesn't handle the covariant case. But, in the MS ABI, there are some cases where vtable thunks must be emitted even when the variadic method defintion is not available, so it looks like we need to implement this. Do it for both ABIs, since it's a nice size improvement and simplification for Itanium. Emit an error when emitting thunks for variadic methods with a covariant return type. This case is essentially not implementable unless the ABI provides a way to perfectly forward variadic arguments without a tail call. Fixes PR43173. Differential Revision: https://reviews.llvm.org/D67028 llvm-svn: 371269
* [DebugInfo] Don't emit incorrect descriptions of thunk params (PR42627)Vedant Kumar2019-07-291-0/+20
| | | | | | | | | | | | | | | | The `this` parameter of a thunk requires adjustment. Stop emitting an incorrect dbg.declare pointing to the unadjusted pointer. We could describe the adjusted value instead, but there may not be much benefit in doing so as users tend not to debug thunks. Robert O'Callahan reports that this matches gcc's behavior. Fixes PR42627. Differential Revision: https://reviews.llvm.org/D65035 llvm-svn: 367269
* IRGen: Add optnone attribute on function during O0Mehdi Amini2017-05-291-1/+1
| | | | | | | | | | | Amongst other, this will help LTO to correctly handle/honor files compiled with O0, helping debugging failures. It also seems in line with how we handle other options, like how -fnoinline adds the appropriate attribute as well. Differential Revision: https://reviews.llvm.org/D28404 llvm-svn: 304127
* Cleanup the handling of noinline function attributes, -fno-inline,Chandler Carruth2016-12-231-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-09-151-7/+23
| | | | | | | | | | | | | | | | | | 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 and other bug caused in chrome. After this patch got reverted because of ScalarEvolution bug (D12719) Merged after John McCall big patch (Added Address). http://reviews.llvm.org/D11859 http://reviews.llvm.org/D12865 llvm-svn: 247646
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Piotr Padlewski2015-09-101-23/+7
| | | | | | | | It seems that there is small bug, and we can't generate assume loads when some virtual functions have internal visibiliy This reverts commit 982bb7d966947812d216489b3c519c9825cacbf2. llvm-svn: 247332
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-09-091-7/+23
| | | | | | | | | | | | | | | | | 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. After this patch got reverted because of ScalarEvolution bug (D12719) Merged after John McCall big patch (Added Address). http://reviews.llvm.org/D11859 llvm-svn: 247199
* Revert r246214 and r246213Steven Wu2015-08-281-25/+7
| | | | | | These two commits causes llvm LTO bootstrap to hang in ScalarEvolution. llvm-svn: 246282
* Assume loads fix #2Piotr Padlewski2015-08-271-2/+4
| | | | | | | | | | | | | There was linker problem, and it turns out that it is not always safe to refer to vtable. If the vtable is used, then we can refer to it without any problem, but because we don't know when it will be used or not, we can only check if vtable is external or it is safe to to emit it speculativly (when class it doesn't have any inline virtual functions). It should be fixed in the future. http://reviews.llvm.org/D12385 llvm-svn: 246214
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-08-271-7/+23
| | | | | | | | | | | | | | | 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: 246213
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Piotr Padlewski2015-08-211-23/+7
| | | | | | | | Reverting because of 245721 This reverts commit 552658e2b60543c928030b09cc9b5dfcb40c3f28. llvm-svn: 245727
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-08-211-7/+23
| | | | | | | | | | | | | | | 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: 245721
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Justin Bogner2015-08-181-23/+7
| | | | | | | | | | | 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-7/+23
| | | | | | | | | | | | | | | 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-23/+7
| | | | | | It caused PR24479 llvm-svn: 245260
* Generating assumption loads of vptr after ctor callPiotr Padlewski2015-08-171-7/+23
| | | | | | | | | | | | 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
* Set comdat when an available_externally thunk is converted to linkonce_odr.Rafael Espindola2015-07-151-0/+17
| | | | | | Fixes pr24130. llvm-svn: 242293
* CodeGen: Do not give local-linkage functions externally available linkage, ↵Peter Collingbourne2015-07-011-0/+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
* Revert r236879, "Do not emit thunks with available_externally linkage in ↵NAKAMURA Takumi2015-05-091-26/+1
| | | | | | | | comdats" It broke pecoff, at least i686-cygwin. llvm-svn: 236937
* Do not emit thunks with available_externally linkage in comdatsDerek Schuff2015-05-081-1/+26
| | | | | | | | | | | | | | 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
* Update Clang tests to handle explicitly typed load changes in LLVM.David Blaikie2015-02-271-1/+1
| | | | llvm-svn: 230795
* Update Clang tests to handle explicitly typed gep changes in LLVM.David Blaikie2015-02-271-6/+6
| | | | llvm-svn: 230783
* Emit DeferredDeclsToEmit in a DFS order.Rafael Espindola2015-01-221-4/+4
| | | | | | | | | | | | | | Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
* Remove the -fhidden-weak-vtables -cc1 option. It was dead,John McCall2014-02-081-4/+5
| | | | | | gross, and increasingly replaced through other mechanisms. llvm-svn: 201011
* CodeGen: Don't emit linkage on thunks that aren't emitted because they're ↵Benjamin Kramer2013-12-071-0/+22
| | | | | | | | | | | | vararg. This can happen when we're trying to emit a thunk with available_externally linkage with optimization enabled but bail because it doesn't make sense for vararg functions. PR18098. llvm-svn: 196658
* CHECK-LABEL-ify some code gen tests to improve diagnostic experience when ↵Stephen Lin2013-08-151-10/+10
| | | | | | tests fail. llvm-svn: 188447
* Fix FileCheck --check-prefix lines.Tim Northover2013-08-121-1/+1
| | | | | | | | | | Various tests had sprung up over the years which had --check-prefix=ABC on the RUN line, but "CHECK-ABC:" later on. This happened to work before, but was strictly incorrect. FileCheck is getting stricter soon though. Patch by Ron Ofir. llvm-svn: 188174
* Reapply r176133 with testcase fixes.Bill Wendling2013-02-271-5/+2
| | | | llvm-svn: 176145
* Revert "Add more attributes from the command line to functions."Anna Zaks2013-02-251-2/+5
| | | | | | | | This reverts commit 176009. The commit is a likely cause of several buildbot failures. llvm-svn: 176044
* Add more attributes from the command line to functions.Bill Wendling2013-02-251-5/+2
| | | | | | | This is an ongoing process. Any command line option which a back-end cares about should be added here. llvm-svn: 176009
* Modify the tests to use attribute group references instead of listing theBill Wendling2013-02-201-1/+6
| | | | | | function attributes. llvm-svn: 175606
* Call CGM.SetLLVMFunctionAttributesForDefinition on thunks so that they getRafael Espindola2012-09-211-2/+17
| | | | | | | attributes like uwtable. Without uwtable a stack unwinder would be unable to go past the thunks. llvm-svn: 164411
* Fix thunk emission for covariant virtual functions in cases which requireEli Friedman2012-09-141-0/+26
| | | | | | both a virtual and a non-virtual offset. PR13832. llvm-svn: 163866
* Complain about attempts to use 'protected' visibility on targetsJohn McCall2012-01-291-2/+2
| | | | | | | | like Darwin that don't support it. We should also complain about invalid -fvisibility=protected, but that information doesn't seem to exist at the most appropriate time, so I've left a FIXME behind. llvm-svn: 149186
* Add an implementation of thunks for varargs methods. The implementation is ↵Eli Friedman2011-05-061-3/+27
| | | | | | a bit messy, but it is correct as long as the method in question doesn't use indirect gotos. A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 . llvm-svn: 130993
* Warn about code that uses variables and functions with internal linkageJohn McCall2011-02-191-23/+21
| | | | | | | | | | | | | | without defining them. This should be an error, but I'm paranoid about "uses" that end up not actually requiring a definition. I'll revisit later. Also, teach IR generation to not set internal linkage on variable declarations, just for safety's sake. Doing so produces an invalid module if the variable is not ultimately defined. Also, fix several places in the test suite where we were using internal functions without definitions. llvm-svn: 126016
* When re-using a vtable slot for the nearest overridden method, just becauseJohn McCall2010-11-091-0/+19
| | | | | | | | | | | | there's no return adjustment from the overridden to the overrider doesn't mean there isn't a return adjustment from the overrider to the final overrider. This matters if we're emitting a virtual this-adjustment thunk because the overrider virtually inherits from the class providing the nearest overridden method. Do the appropriate return adjustment in this case. Fixes PR7611. llvm-svn: 118466
* Just disable the hidden-visibility optimization for now by hiding it behindJohn McCall2010-08-121-3/+4
| | | | | | | | a -cc1 option. The Darwin linker complains about mixed visibility when linking gcc-built objects with clang-built objects, and the optimization isn't really that valuable. Platforms with less ornery linkers can feel free to enable this. llvm-svn: 110979
* Extend the visibility-hidden optimization to linkonce_odr thunks forJohn McCall2010-08-041-1/+14
| | | | | | | | | functions with in-line definitions, since such thunks will be emitted at any use of the function. Completes the feature work for rdar://problem/7523229. llvm-svn: 110285
* Don't try to emit the vtable for a class just because we're emitting aJohn McCall2010-06-021-0/+12
| | | | | | | | virtual function from it. Fixes PR7241. llvm-svn: 105345
* Correctly pass aggregates by reference when emitting thunks.John McCall2010-05-261-0/+18
| | | | llvm-svn: 104778
* When generating the call arguments in a thunk to call the thunkee, doDouglas Gregor2010-05-211-0/+45
| | | | | | | | not make copies non-POD arguments or arguments passed by reference: just copy the pointers directly. This eliminates another source of the dreaded memcpy-of-non-PODs. Fixes PR7188. llvm-svn: 104327
* When creating a this-adjustment thunk where the return value is of C++Douglas Gregor2010-05-201-4/+45
| | | | | | | | | class type (that uses a return slot), pass the return slot to the callee directly rather than allocating new storage and trying to copy the object. This appears to have been the cause of the remaining two Boost.Interprocess failures. llvm-svn: 104215
* Rework when and how vtables are emitted, by tracking where vtables areDouglas Gregor2010-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* Give thunks the same linkage as their original methods.Anders Carlsson2010-03-271-4/+25
| | | | llvm-svn: 99729
* Flip the switch and use the new vtable layout code for thunks by default. ↵Anders Carlsson2010-03-241-0/+116
Add a thunks.cpp test. llvm-svn: 99367
OpenPOWER on IntegriCloud