http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- "hubicka at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 > >Jan Hubicka <hubicka at gcc dot gnu.org> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Last reconfirmed| |2013-12-17 > CC| |hubicka at gcc dot gnu.org, > | |mjambor at suse dot cz, > | |rguenther at suse dot de > Ever confirmed|0 |1 > >--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> --- >Couple years later we finally devirtualize here: > <bb 5>: > ap_8 = operator new (16); > ap_8->i = 0; > ap_8->_vptr.A = &MEM[(void *)&_ZTV1A + 16B]; > _19 = foo; > PROF_26 = [obj_type_ref] OBJ_TYPE_REF(_19;(struct A)ap_8->0); > if (PROF_26 == foo) > goto <bb 8>; > else > goto <bb 7>; > > <bb 6>: > ap_13 = operator new (16); > MEM[(struct B *)ap_13].D.2237.i = 0; > MEM[(struct B *)ap_13].b = 0; > MEM[(struct B *)ap_13].D.2237._vptr.A = &MEM[(void *)&_ZTV1B + 16B]; > _1 = foo; > PROF_30 = [obj_type_ref] OBJ_TYPE_REF(_1;(struct A)ap_13->0); > if (PROF_30 == foo) > goto <bb 8>; > else > goto <bb 7>; > >however the code ends up super sily after tracer. >for some reason we do not manage to fold away the virtual table lookup. >Why? This is probably doms fault. Does it even handle function pointers? Tracer runs way too late and with no cleanups behind it.
