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