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