> On Wed, 20 Apr 2011, Jan Hubicka wrote: > > > > Hi, > > > > > > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote: > > > > Actually what happens here is that CCP devirtualize by propagating the > > > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we > > > > finally get > > > > a direct call. This is all good and desirable. > > > > > > > > I think good solution would be to fold further and inline the thunk > > > > adjustment, just like the type based devirtualization does. Even > > > > once I get far enough with my cgraph cleanuping project to make > > > > cgraph represent thunks nicely, we would win if in these cases ccp > > > > and other passes simply inlined the this adjustment, like we do with > > > > type based devirtualization already. > > > > > > > Martin, I guess it is matter of looking up the thunk info by > > > > associated cgraph node alias and extending fold_stmts of passes that > > > > now drop the OBJ_TYPE_REF wrappers? > > > > > > Well, if you have a cgraph node then yes. But if the method is > > > implemented in a different compilation unit you don't. And as I > > > already said today on IRC, I don't think it is possible to tell > > > whether a function is a thunk by looking at the decl alone (the front > > > hand has a flag for it as Jakub noted, though), let alone what kind of > > > thunk it is. > > > > Well, you don't care about thunks resisting in other unit/partition... > > Sure you do - LTO might bring them into scope if you fold them to > a direct call early.
Well, we do have way to represent the thunk adjust over edges and lto-symtab can just feed the data in while merging external decl with thunk. Honza > > Richard.
