[PATCH] D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible
Teresa Johnson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 5 09:08:04 PDT 2019
tejohnson marked an inline comment as done.
tejohnson added inline comments.
================
Comment at: llvm/trunk/lib/LTO/LTO.cpp:334
+ S->setCanAutoHide(VI.canAutoHide() &&
+ !GUIDPreservedSymbols.count(VI.getGUID()));
+ }
----------------
tejohnson wrote:
> steven_wu wrote:
> > The regression I saw is exactly the situation mentioned in the comments but I am not so sure about the conclusion here. For ld64, it can see whether a symbol can be auto hide or not, and it prefers the one that is not auto hide. This means if there are other copies of the symbol that is not autohide outside the summary and not autohide, the one can be autohide should never be prevailing.
> >
> > Is that the case for other linker?
> > The regression I saw is exactly the situation mentioned in the comments but I am not so sure about the conclusion here.
>
> By the situation mentioned in the comments I assume you mean the part about symbols in the GUIDPreservedSymbols set because they are visible outside the summary? In your situation, why are there so many symbols in the preserved symbols set? Are there a lot of symbols in native code being linked in?
>
> I guess it is different in lld since in the case I encountered (in an internal application), the linkonce_odr copy was prevailing, not the weak_odr copy. If ld64 guarantees that the autohide (linkonce_odr) copy will never be prevailing if there is an autohide (weak_odr) copy available somewhere, then we may need to figure out a way to communicate that.
> If ld64 guarantees that the autohide (linkonce_odr) copy will never be prevailing if there is an autohide (weak_odr) copy available somewhere
I meant if there is a *non*-autohide (weak_odr) copy available of course...
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59709/new/
https://reviews.llvm.org/D59709
More information about the llvm-commits
mailing list