summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
diff options
context:
space:
mode:
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>2014-08-12 16:46:37 +0000
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>2014-08-12 16:46:37 +0000
commit09d84addb77e7ddf6a430ea79174ec123e9d3581 (patch)
treed7c5020953b8175e1e638fbd02d44267927d16b3 /llvm/lib/CodeGen
parent1a9c0d141c22a2f677af2a2652c45911637f4cb1 (diff)
downloadbcm5719-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
OpenPOWER on IntegriCloud