aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorJez Ng <jezng@fb.com>2021-02-25 13:27:40 -0500
committerJez Ng <jezng@fb.com>2021-02-25 13:27:40 -0500
commit84579fc24f03c8ca778e70325dad2166f1deaee3 (patch)
tree61ed46c852bb03e585bf0b27d5afbc8fcbfe9e24 /clang/lib/Frontend/CompilerInvocation.cpp
parentd9c99043bdde5637bf32edaad10d1b8f8cd10b38 (diff)
downloadllvm-84579fc24f03c8ca778e70325dad2166f1deaee3.zip
llvm-84579fc24f03c8ca778e70325dad2166f1deaee3.tar.gz
llvm-84579fc24f03c8ca778e70325dad2166f1deaee3.tar.bz2
[lld-macho] Basic support for linkage and visibility attributes in LTO
When parsing bitcode, convert LTO Symbols to LLD Symbols in order to perform resolution. The "winning" symbol will then be marked as Prevailing at LTO compilation time. This is similar to what the other LLD ports do. This change allows us to handle `linkonce` symbols correctly, and to deal with duplicate bitcode symbols gracefully. Previously, both scenarios would result in an assertion failure inside the LTO code, complaining that multiple Prevailing definitions are not allowed. While at it, I also added basic logic around visibility. We don't do anything useful with it yet, but we do check that its value is valid. LLD-ELF appears to use it only to set FinalDefinitionInLinkageUnit for LTO, which I think is just a performance optimization. From my local experimentation, the linker itself doesn't seem to do anything differently when encountering linkonce / linkonce_odr / weak / weak_odr. So I've only written a test for one of them. LLD-ELF has more, but they seem to mostly be testing the intermediate bitcode output of their LTO backend...? I'm far from an expert here though, so I might very well be missing things. Reviewed By: #lld-macho, MaskRay, smeenai Differential Revision: https://reviews.llvm.org/D94342
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions