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

[Rafael Espíndola]

>> -    // 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? What is the linker error? Do any of the .o files were produced
by clang [
194000,r194095)?

Cheers,
Rafael