pretty-ipa merge part 19: Clonning infrastructure

[Jan Hubicka]

> 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
tracer is.

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
updated.
> 
> 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
is not.

Honza
> 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
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713