[PATCH] Don't upgrade global constructors when reading bitcode

[Rafael Espíndola]

This is fine by me. Nick?

On 5 August 2014 01:43, Reid Kleckner <rnk at google.com> wrote:
> I was hoping Nick would throw in his two cents.  :)
>
>
> On Thu, Jul 31, 2014 at 2:26 PM, Duncan P. N. Exon Smith
> <dexonsmith at apple.com> wrote:
>>
>> An optional third field was added to `llvm.global_ctors` (and
>> `llvm.global_dtors`) in r209015.  Most of the code has been changed to
>> deal with both versions of the variables.  Users of the C API might
>> create either version, the helper functions in LLVM create the two-field
>> version, and clang now creates the three-field version.
>>
>> However, the BitcodeReader was changed to always upgrade to the
>> three-field version.  This created an unnecessary inconsistency in the
>> IR before/after serializing to bitcode.
>>
>> This commit resolves the inconsistency by making the third field truly
>> optional (and not upgrading in the bitcode reader).  Since `llvm-link`
>> was relying on this upgrade code, rather than deleting it I've moved it
>> into `ModuleLinker`, where it upgrades these arrays as necessary to
>> resolve inconsistencies between modules.
>>
>> I changed `test/Bitcode/upgrade-global-ctors.ll` to a negative test and
>> duplicated the `llvm-link` check in `test/Linker/global_ctors.ll` to
>> check both upgrade directions.  Since I came across this as part of
>> PR5680 (serializing use-list order), I've also added a RUN line to
>> `test/Bitcode/metadata-2.ll`.
>>
>> The ideal resolution would be to remove the 2-field version and make the
>> third field required.  I filed PR20506 to track that.
>>
>