Re: RFA: New ipa-devirt PATCH for c++/58678 (devirt vs. KDE)

[Jason Merrill <jason at redhat dot com>]

On 03/11/2014 05:08 PM, Jan Hubicka wrote:
> Jason, I was looking into this and I think I have patch that works.  I would
> just like to verify I inderstnad things right.  First thing I implemented is to
> consistently skip dtors of abstract classes as per the comment in
> abstract_class_dtor_p there is no way to call those by virtual table pointer.
> Unlike your patch it will i.e. enable better unreachable code removal since
> they will not appear in possible target lists of polymorphic calls.

Makes sense.

> The second change I did is to move methods that are reachable only
> via abstract class into the part of list that is in construction,
> since obviously we do not have instances of these classes.

I'm not sure how you would tell that a method that is reachable only via 
abstract class; a derived class doesn't have to override methods other 
than the destructor, so we could get the abstract class method for an 
object of a derived class.

> What I would like to verify with you shtat I also changed walk when looking
> for destructors to not consider types in construction. I believe there is no way
> to get destructor call via construction vtable as we always know the type.
> Is that right?

I guess it would be possible to get the abstract destructor via 
construction vtable if someone deletes the object while it's being 
constructed.  But surely that's undefined behavior anyway.

> also if abstract_class_dtor_p functions are never called via vtables, is there
> reason for C++ FE to put them there? I understand that there is a slot in vtable initializer
> for them, but things would go smoother if it was initialized to NULL or some other marker
> different from cxa_pure_virtual.  Then gimple-fold will already substitute it for
> builtin_unreachable and they will get ignored during the ipa-devirt's walks.

Hmm, interesting idea.  Shall I implement that?

Jason