This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH for c++/61687 (extra errors with -O2)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 25 Jul 2014 01:36:17 +0200
- Subject: Re: C++ PATCH for c++/61687 (extra errors with -O2)
- Authentication-results: sourceware.org; auth=none
- References: <53BEE83C dot 2000700 at redhat dot com> <20140717122316 dot GA19997 at atrey dot karlin dot mff dot cuni dot cz> <53D18535 dot 9040006 at redhat dot com>
> >Given my experience about numbers of functions that become reachable when you stream all virtuals into LTO,
> >I wonder if we don't want to use possible_polymorphic_call_targets within the front-end to avoid instantiating
> >those that can't be called?
> Yes, I think we need to do that. I'll look into it.
> >I think it should not be too hard - all we need is to populate the type inheritance graph from FE and then
> >for each polymorphic call produce the list to mark possible targets are reachable.
> Hmm, do you think it's reasonable to call
> build_type_inheritance_graph from the FE? The FE doesn't currently
> track all types derived from a particular base.
ipa-deivrt has code to do the tracking for you. All is needed is to cal get_odr_type
for all polymorphic type that we care about. build_type_inheritance_graph just
walks all virtual methods to register all polymorphic types that matters (i.e.
have methods associated with them) into the datastructure. I think within C++
FE we can just reigster all polymoprhic types we produce.
I see that during the reachability walk new types may be instantiated. This may
extend target lists earlier visited, I guess we need to add some way to make
to track this?