[PATCH] Don't upgrade global constructors when reading bitcode
Reid Kleckner
rnk at google.com
Mon Aug 4 22:43:59 PDT 2014
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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140804/dbda91b6/attachment.html>
More information about the llvm-commits
mailing list