This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Issues with intraprocedural devirtualization


> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]