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: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)


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.

Richard.


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