summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/devirtualize-virtual-function-calls-final.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Sema] Mark a virtual CXXMethodDecl as used if a call to it can beAkira Hatanaka2017-07-131-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devirtualized. The code to detect devirtualized calls is already in IRGen, so move the code to lib/AST and make it a shared utility between Sema and IRGen. This commit fixes a linkage error I was seeing when compiling the following code: $ cat test1.cpp struct Base { virtual void operator()() {} }; template<class T> struct Derived final : Base { void operator()() override {} }; Derived<int> *d; int main() { if (d) (*d)(); return 0; } rdar://problem/33195657 Differential Revision: https://reviews.llvm.org/D34301 llvm-svn: 307883
* [CodeGen] Devirtualize calls to methods marked final in a derived classVedant Kumar2016-10-201-0/+16
| | | | | | | | | | If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
* Fix incorrect codegen for devirtualized calls to virtual overloaded operators.Nico Weber2014-12-031-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider this program: struct A { virtual void operator-() { printf("base\n"); } }; struct B final : public A { virtual void operator-() override { printf("derived\n"); } }; int main() { B* b = new B; -static_cast<A&>(*b); } Before this patch, clang saw the virtual call to A::operator-(), figured out that it can be devirtualized, and then just called A::operator-() directly, without going through the vtable. Instead, it should've looked up which operator-() the call devirtualizes to and should've called that. For regular virtual member calls, clang gets all this right already. So instead of giving EmitCXXOperatorMemberCallee() all the logic that EmitCXXMemberCallExpr() already has, cut the latter function into two pieces, call the second piece EmitCXXMemberOrOperatorMemberCallExpr(), and use it also to generate code for calls to virtual member operators. This way, virtual overloaded operators automatically don't get devirtualized if they have covariant returns (like it was done for regular calls in r218602), etc. This also happens to fix (or at least improve) codegen for explicit constructor calls (`A a; a.A::A()`) in MS mode with -fsanitize-address-field-padding=1. (This adjustment for virtual operator calls seems still wrong with the MS ABI.) llvm-svn: 223185
* Fix bug 20116 - http://llvm.org/bugs/show_bug.cgi?id=20116Alexey Bataev2014-09-291-3/+6
| | | | | | | | Fixes incorrect codegen when devirtualization is aborted due to covariant return types. Differential Revision: http://reviews.llvm.org/D5321 llvm-svn: 218602
* CHECK-LABEL-ify some code gen tests to improve diagnostic experience when ↵Stephen Lin2013-08-151-10/+10
| | | | | | tests fail. llvm-svn: 188447
* When we're devirtualizing a method call, make sure the method has the ↵Eli Friedman2012-10-251-2/+1
| | | | | | | | correct IR type. Reported in the thread "devirtualisation appears to crash clang on covariant functions on ARM" on cfe-dev. llvm-svn: 166651
* A number of test cases assume that an "int" parameter or return valueUlrich Weigand2012-10-241-1/+1
| | | | | | | | | | | | will be represented in the IR as a plain "i32" type. This causes the tests to spuriously fail on platforms where int is not a 32-bit type, or where the ABI requires attributes like "signext" or "zeroext" to be used. This patch adds -triple or -target parameters to force those tests to use the i386-unknown-unknown target. llvm-svn: 166551
* Disable devirtualization when we have covariant returns. I will open a bugRafael Espindola2012-06-281-0/+34
| | | | | | for tracking this. llvm-svn: 159351
* Don't devirtualize calls when we don't have the correct type of the this pointerRafael Espindola2012-06-281-1/+20
| | | | | | | | | handy. It can be done, but we would have to build a derived-to-base cast during codegen to compute the correct this pointer. I will handle covariant returns next. llvm-svn: 159350
* Fix another issue with devirtualizing calls to final methods by passing themRafael Espindola2012-06-281-0/+26
| | | | | | | | the correct this pointer. There is some potential for sharing a bit more code with canDevirtualizeMemberFunctionCalls, but that can be done in an independent patch. llvm-svn: 159326
* During codegen of a virtual call we would extract any casts in the expressionRafael Espindola2012-06-261-1/+59
| | | | | | | | to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
* When trying to get the most derived class, don't assume that we can ignore ↵Anders Carlsson2011-01-291-0/+12
| | | | | | all casts. We can only ignore derived-to-base and no-op casts. Fixes selfhost. llvm-svn: 124528
* When calling a virtual member function on a base class and the most derived ↵Anders Carlsson2011-01-291-0/+14
| | | | | | class is marked 'final', we can devirtualize the call. llvm-svn: 124524
* Get rid of the [[final]] C++0x attribute.Anders Carlsson2011-01-231-0/+25
llvm-svn: 124083
OpenPOWER on IntegriCloud