[PATCH] Use aliases instead of separate copies for !DECL_ONE_ONLY C[12] ctors or D[12] dtors with identical bodies (PR c++/3187, take 2)

[Jan Hubicka]

> 
> At least for the cdtor COMDAT aliases I need to output either all of them
> (if any of them is needed), or none of them.  Otherwise the COMDAT group
> could provide different symbols between different CUs and we'd lose.

Ah, if you unify only within single unit only, then this should be safe, yes.

At present we are freely removing DECL_COMDAT functions when not dead without
looking into COMDAT groups.  As we happen to have multiple in the same group
without any other means of knowing that we need to keep either all of them or
none?  We would need to update unreachable functions removal otherwise.
> > 
> > I don't get this.  You have functions a,b,c,d in same body group and you
> > make cgraph so all calleers ends going to a, then you constant propagate
> > and discover that first argument of a is always 1 but a/b/c/d are also
> > exported from unit, so you decide to clone.
> > In this case you want to update all the calls no matter if they go to
> > a,b,c, or d, since they are all having first argument of 1.
> 
> This was to cure something I've noticed when eyeballing the output.
> Which symbol is the real one and what are the aliases is quite arbitrary
> choice, and without this hunk cgraph_materialize_all_clones was rewriting
> all the calls to the real fn.  That's IMNSHO undesirable, if some function
> calls _ZN1SD1Ev, we shouldn't change that call to _ZN1SD2Ev just because
> we made in this CU an arbitrary choice to emit _ZN1SD2Ev as the real
> function and _ZN1SD1Ev as an alias to it.  The call relocation will be
> visible in the object file (unlike what was the real function and what were
> the aliases).  While if in one CU we decided that both destructors are
> identical they'd better be identical in all other CUs, shared libraries,
> etc., it is still IMHO a good idea not to rewrite the callers needlessly.
> People might be surprised why the code calls say base dtor when it is
> supposed to call complete dtor, etc.

Ah, I see, you got redirection because of test
if (decl && decl != e->callee->decl)
matching.  I guess your code is safe then, as long as if we decide to clone we
will actually redirect (that we should since clone won't be in the same bod
group).

> 
> > Also can it happen for a/b/c/d to have different visibilities? (ie. some
> > externally visible, others not?)
> 
> Currently they must have the same visibilities, same TREE_PUBLIC, etc.

Yes, then we should be safe.  It would be nice to move all aliases to this
interface since it works with IPA optimizers, but that will be more work (and
soemthing for 4.6)

Java also does tons of aliases from FE to accomodate its API, I wonder if those
can use this API isntead of the current aliasing to enable more IPA on Java?

Cgraph bits are OK then if you add the LTO support.

Thanks,
Honza
> 
> 	Jakub