r194095 - Produce direct calls instead of alias to linkonce_odr functions.

[Chandler Carruth]

On Tue, Nov 12, 2013 at 6:18 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> >> -    // In addition to making sure we produce it in every TU, we have to
> >> make
> >> -    // sure llvm keeps it.
> >
> >
> > This comment ^^^ seems to very clearly indicate that there is a need for
> > other TUs to be able to reference this alias. (The second part of the
> > comment that is...)
>
> The issue is not that other TU reference it. It is that every comdat
> must be identical. Since we don't have direct support for comdats in
> the LLVM ir yet, what the old code was doing was using a weak_odr
> alias.
>
> The new code simply replaces anything that would use one of the
> linkonce_odr destructors with the one we know it is equivalent to.
>
> >>
> >> -    // FIXME: Instead of outputting an alias we could just replace
> every
> >> use of
> >> -    // AliasDecl with TargetDecl.
> >> -    assert(Linkage == TargetLinkage);
> >> -    Linkage = llvm::GlobalValue::WeakODRLinkage;
> >
> >
> > And yet the code that replaces this:
> >
> >> +    // Instead of creating as alias to a linkonce_odr, replace all of
> the
> >> uses
> >> +    // of the aliassee.
> >> +    if (TargetLinkage == llvm::GlobalValue::LinkOnceODRLinkage) {
> >> +      Replacements[MangledName] = Aliasee;
> >> +      return false;
> >> +    }
> >
> >
> > This doesn't preserve the same set of invariants the code above seems to
> > indicate are needed: the ability for there to be a weak ODR alias emitted
> > into this TU.
> >
> > So, what's going on here? Any ideas? Hopefully Nick can add a test case
> when
> > the reduction finishes.
>
> In hindsight the change to use a weak_odr alias to a linkonce_odr
> destructor was a bad hack around not having comdats. GCC always puts
> D1 and D2 in a comdat when they alias, but having direct comdat
> support means it can use a new name for the comdat, which avoid
> problems when mixing old and new object files.
>
> LLVM puts weak symbols in comdats, but we have no way of controlling
> the name and need hacks to make sure they are identical in every TU.
> This works when everything is using that clang or gcc, but can cause
> problems with .o files from different version of clang since the
> linker will see comdats with different symbols in them.
>
> Can you check if the comdats are identical in the link issue you are
> having?


Not sure, Nick or Eric may be able to provide more details.

What is the linker error?


"warning: relocation refers to discarded section"


> Do any of the .o files were produced
> by clang [
> 194000,r194095)?
>

Not in a ready-for-test-case form.

This still seems like it is fundamentally breaking ABI with old clang
versions, and potentially with GCC. I'm not sure we should do this, and I
would like to not do this without some lead time to test it out. Certainly,
it is currently blocking everything we do with Clang internally, literally
everything is broken. =[ Can you at least go back to emitting the weak_odr
alias so that link steps which rely on this continue to work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131112/3c1e74bd/attachment.html>