This is the mail archive of the
mailing list for the GCC project.
Re: Type inheritance graph analysis & speculative devirtualization, part 2/6 (type inheritance graph builder)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, marxin dot liska at gmail dot com, jason at redhat dot com, mjambor at suse dot cz, davidxl at google dot com
- Date: Mon, 19 Aug 2013 10:20:54 +0200
- Subject: Re: Type inheritance graph analysis & speculative devirtualization, part 2/6 (type inheritance graph builder)
- References: <20130818181957 dot GA12682 at kam dot mff dot cuni dot cz> <b375a917-3db8-4cae-b6e3-d571ba9eec11 at email dot android dot com>
> I believe you can get derived objects of derived type not visible in the tu, so the list of targets does only contain local methods and implicitly all methods only defined in other tus? That is, you cannot rely no that list to be complete?
Yes, the list is in majority cases not complete. It is complete when you deal
with virtual method comming from object in local namespaces or final
classes/methods (this info we do not pass to middle-end yet). There is "final"
flag passed from possible_polymorphic_call_targets to you saying when this
I am currently using it for compile time unreachable code removal. I.e. to
remove known to be unreachable comdat&external virtual function bodies rather
then pickling them all to LTO and remove them post inlining when we assume
devirt to no longer happen. I alos use it for speculative devirtualization
(i.e when I only see one possible virtual call candidate on LTO I believe it is
likely to be the one called on runtime).
There are some cases where you can get more complete information but in general
this is not meant to replace the current code that is tracking lists of
possible dynamic object types reaching to given call. It is kind of ortoghonal