[cfe-commits] r159326 - in /cfe/trunk: include/clang/AST/Expr.h lib/AST/Expr.cpp lib/CodeGen/CGExprCXX.cpp test/CodeGenCXX/devirtualize-virtual-function-calls-final.cpp

[Rafael Espíndola]

> Inner (and therefore "this") will indeed have type MostDerivedClassDecl
> here, but that's not necessarily the type that declares the final override for
> the method being called:
>
>  struct Primary { virtual ~Primary(); void *member; };
>
>  struct A { virtual void foo(); }; // its own final override
>  struct final B : Primary, A {}; // most derived
>  void test(B *b) {
>    b->foo();
>  }
>
> My example happens to have us devirtualize to the original method,
> but that's not necessarily the case;  you can have arbitrary inheritance
> and overriding between A and the most-derived class, like so:
>
>  struct A { virtual void foo(); };
>  struct B : A { virtual void foo(); }; // final override
>  struct final C : Primary, B {}; // most derived
>  void test(C *c) {
>    static_cast<A*>(c)->foo();
>  }
>
> And of course the offset from A to B doesn't have to be zero, either:
>
>  struct A { virtual void foo(); };
>  struct B : Primary, A { virtual void foo(); }; // final override
>  struct final C : Primary, B {}; // most derived
>  void test(C *c) {
>    static_cast<A*>(d)->foo();
>  }
>
> Really, you have to do a derived-to-base conversion from the most-derived
> class to the base actually declaring the method.  Fortunately, that can't
> actually fail (they can in general, due to ambiguity) because of the
> well-formedness constraints on final overriders.

Thanks!

I think a valid summary is that there are 3 types we have to consider:

1 The type of the expression
2 The type of the most derived dynamic class we can find
3 The type of the class defining the method we want to call

Computing the this pointer is simple when type 3 is the same as type 1
or 2. When that is not the case we have to construct a cast, which
doesn't look trivial to do from CodeGen given that the methods for
handling CXXCastPath are in sema (should we do part of the
devirtualization in sema?).

My current idea is to just drop the optimization when type 3 is not
equal to type 1 or 2. The attached hackish patch does that. I will try
to clean it up in the morning, but now I need some sleep :-)

> John.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 4530 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120628/c12e29b7/attachment.obj>