This is the mail archive of the
mailing list for the GCC project.
Re: pretty-ipa merge part 19: Clonning infrastructure
> Richard Guenther wrote:
> > The proper fix is to defer to the inliner to do the cloning and to
> > re-implement thunks like Diego suggested for LTO.
> Well, I think the *proper* fix is to implement multiple entry points,
> and then use that. Both clones and thunks are really multiple entry
> points, and especially in the case of clones, using multiple entry
> points would reduce code size with very little cost in time, if any.
Well, the clonning ipa-cp does is more about improving performance by
specializing function body for known constant, so multiple entry points
won't help unless we implement better code specialization pass than
But yes, I would like to have multiple entry points too. I had plan on
that implementing them in working condition first in backend and get
them working for i386 -fPIC and register calling convention. Have
patches for that that was working years back, but I never got approval
for dwarf updates needed. I will try to dig it out and see if it can be
> In any case, for right now...
> IIRC, the C++ ABI implies that when you emit one clone, you must emit
> them all. Otherwise, you end up with confusion if one COMDAT section
> has one clone and another COMDAT section with the same name has the
> other. So, the situation Jan is describing where we end up with the
> clone, but not the original function, sounds like a bad thing. It
The clones produced by ipa-cp are not visible and not living in COMDAT
section. THey are simple static functions copying body of the function
that was originally in COMDAT section (or externally visible). So I
think all we need is to prevent the thunk from being mistakely emit when
this ipa-cp clone is produced and output, because the original function
> sounds like we need to prevent that. I thought we had already done
> that, via explicit calls in the C++ front end to mark functions needed,
> but perhaps I am wrong -- or perhaps something changed?
> Mark Mitchell
> (650) 331-3385 x713