[lld] r301438 - LTO: Mark undefined module asm symbols as used.

Peter Collingbourne via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 27 12:42:30 PDT 2017


On Thu, Apr 27, 2017 at 11:56 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> > Right, although I'd expect that taking the address in llvm.compiler.used
> > would have already prevented those sorts of optimizations.
> >
> > The other thing is that we may be using linkage in the midend as an
> > optimization hint (for example, we may use a higher inlining threshold
> for
> > functions with internal linkage). But I'd expect those kinds of hints to
> > only apply to functions whose address is not taken (i.e. by
> > llvm.compiler.used). So we should be in the same position as before.
>
> True, so it was really just saving a symbol from the symbol table.
> That helps the dynamic linker a bit, but it is hard to imagine a case
> with so many of these that it would make a difference.
>

If a symbol needs to be added to the dynamic symbol table, I would expect
it to be marked as used by the linker (i.e. VisibleToRegularObj), and in
fact that is what lld does. That would mean that it could not have been
internalized before. So I think it actually makes no difference (except
perhaps to the static symbol table, but that isn't important).

Was this the last use of llvm.compiler_used?
>

The correct spelling is "llvm.compiler.used", and it looks like we are
still using it in a few places (including the legacy LTO API).
http://llvm-cs.pcc.me.uk/?q=%22llvm%5C.compiler%5C.used%22

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170427/d7647733/attachment.html>


More information about the llvm-commits mailing list