This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Issues with intraprocedural devirtualization
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Jason Merrill <jason at redhat dot com>, rguenther at suse dot de, mjambor at suse dot cz, gcc-patches at gcc dot gnu dot org
- Date: Sun, 18 Aug 2013 10:55:27 +0200
- Subject: Re: [RFC] Issues with intraprocedural devirtualization
- References: <20130817214457 dot GA7313 at kam dot mff dot cuni dot cz> <52101BC9 dot 3090801 at redhat dot com> <20130818085303 dot GB16557 at kam dot mff dot cuni dot cz>
> > On 08/17/2013 05:44 PM, Jan Hubicka wrote:
> > > 1) we want the type to not have base because we may have inlined the constructor.
> > > During construction the vtables are filled by base's vtable and thus we can
> > > not simply devirtualize based on the final virtual table without proving that
> > > constructor was not (partially) inlined.
> >
> > If the constructor is inlined into the current function, then we can
> > see the most recent assignment to the vptr and use that for
> > devirtualization.
>
> In most cases, yes. There are some special issues, like partial inlining
> (where the "wrong" assignment gets inlined, but the final assignment not) But I
> think tracking inlining those (it will need to make middle end aware of
^^^^^ of constructors, partial or not.
> constructors that I think is good idea anyway) and leaving those to the
> constant propagation should work well enough in practice.
Basicaly if ctor of given type was inlined, we will make the assumption that the
type can be partially constructed.
> > >Finally I decided to replace the lookup of base binfo by call to
> > >get_binfo_at_offset. This is not possible. For example my base
> > >variable can be:
> > >
> > >struct {class A a; class B b} var;
> > >
> > >and offset 10 may point to class B. Here I get an ICE since TYPE_BINFO
> > >of the structure is NULL (it is not class).
> >
> > I don't understand. In C++ a struct is a class.
>
> You are right. I get the ICE here only why I handle arrays and unions, too.
^^^ when
> (as I do in my tree, but not in the patches posted). In the example above
> the struct seems to have TYPE_BINFO even though it is useless.
>
> Since handling arrays and union seems to make sense and resolves some real
> testcases from firefox, I think we could keep the tree structured in a way
> making this possible. I.e. having the type walk as proposed in the patch
> instead of calling get_binfo_at_offset.
Honza