diff options
author | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2014-08-12 16:46:37 +0000 |
---|---|---|
committer | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2014-08-12 16:46:37 +0000 |
commit | 09d84addb77e7ddf6a430ea79174ec123e9d3581 (patch) | |
tree | d7c5020953b8175e1e638fbd02d44267927d16b3 /llvm/lib/CodeGen | |
parent | 1a9c0d141c22a2f677af2a2652c45911637f4cb1 (diff) | |
download | bcm5719-llvm-09d84addb77e7ddf6a430ea79174ec123e9d3581.tar.gz bcm5719-llvm-09d84addb77e7ddf6a430ea79174ec123e9d3581.zip |
Don't upgrade global constructors when reading bitcode
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.
The ideal resolution would be to remove the 2-field version and make the
third field required. I filed PR20506 to track that.
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 the missing `verify-uselistorder` RUN line to
`test/Bitcode/metadata-2.ll`.
llvm-svn: 215457
Diffstat (limited to 'llvm/lib/CodeGen')
0 files changed, 0 insertions, 0 deletions