On Thu, 6 Sep 2012, Martin Jambor wrote: > 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 <hubi...@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.
Yes, and related to thunks we also discussed to explicitely represent multiple entry points (which thunks are). Richard.
