This is the mail archive of the gcc@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: Cgraph Modification Plan


Hi,

(I'm CCing the gcc mailing list too since I suppose it is an accident
that it wasn't in the message I'm replying to)

On Thu, Sep 06, 2012 at 09:22:27AM +0200, Jan Hubicka wrote:
> > On Thu, Sep 6, 2012 at 12:08 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > >> > Consequentely you need to track to
> > >> > which specific alias call/reference is going.  So we ended up doing this only
> > >> > for same body aliases
> > >>
> > >> I was actually referring to same-body aliases which are more common in
> > >> C++.  Weak aliases look like different animals.
> > >
> > > The handling of aliases was unified in 4.7, hope you will find it convenient.
> > > I think it is improvement over what we have before.
> > >>
> > >> >and eventually I got convinced to reorg the code other
> > >> > way (in 4.7) so the aliases are all explicitely referenced.
> > >> >
> > >> > Except for need to walk the alises to real node and work out the visibility,
> > >> > there is not much to worry about. Sadly I do not think aliases can be fully
> > >> > hidden in the abstraction - you need to actually think of them when doing many
> > >> > of IPA transforms.
> > >> >
> > >> >>
> > >> >> Thunks are only referenced from vtables. Is there a need to create
> > >> >> cgraph nodes for them?
> > >> >
> > >> > This is not really true. thunks may get into code via constant folding or LTO
> > >> > unit merging. We used to disallow direct calls to thunks in 4.6 and earlier but
> > >> > decided to lift this restriction in 4.7.
> > >>
> > >> Why is that? Should the thunk code be inline expanded (e.g, in profile
> > >> guided icall promotion)? There is no real need for thunk direct
> > >> references, right?
> > >
> > > Well, I was trying to go down this route, too.  We discussed it for a long while and eventually
> > > decided to give it up.  There are many interesting side cases.
> > > For example we may devirtualize call in one unit before LTO streaming and this devirtualized
> > > call may turn out to be tunk in other unit at WPA time when we can not easilly inline the
> > > thunk code.
> > 
> > I don't quite get this. Is the discussion thread available?
> 
> I think it went mostly on the IRC. Richard/Martin?

Well, great deal of it on IRC too but the most infamous relevant bug
was PR 48674 (you might also want to look at PRs 45605 and 48661 to
get the bigger picture).

It was gross, the world is much better with explicit representation of
thunks.

Martin


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