[llvm-dev] ThinLTO and linkonce_odr + unnamed_addr

[Mehdi AMINI via llvm-dev]

2018-02-07 13:23 GMT-08:00 Reid Kleckner <rnk at google.com>:

> On Wed, Feb 7, 2018 at 11:35 AM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>> > From looking at the code, it seems like LLVM is basically opting MachO
>> into -fvisibility-inlines-hidden all the time, i.e. if the function is
>> linkonce, it's discardable, so mark it hidden to pretend the compiler
>> inlined it and discarded it. However, this isn't conforming, because the
>> addresses of inline functions will no longer compare equal across DSOs.
>>
>> I think there is a nuance, it is marking these as "auto-hide": it just
>> means that the address is not taken in the current compilation unit IIRC.
>> The linker decides that it can hide it in the DSO if none of the
>> compilation unit is using the address based on this auto-hide flag.
>>
>> Does it make sense?
>>
>
> Yeah, I missed that. .weak_def_can_be_hidden is a MachO thing that I'm not
> familiar with. It's nice that the format supports it. :)
>
> Perhaps instead we should make ThinLTO responsible for doing the
> auto-hiding, then? It could do the check of, are all declarations marked
> local_unnamed_addr, if so, make it weak_odr + unnamed_addr +
> visibility=hidden?
>

Possibly, I don't remember the details of the plan: it may depend if the
symbol is required by the linker to be exported outside of the DSO?

This situation (and similar others about linkage changes) is a large part
of what motivated originally the new "resolution" LTO API: it offers a much
finer grain for the linker to express the constraint around this. The goal
was to be able to make these decisions very accurately regardless of the
situation. For instance a symbol in LTO can be referenced from a non-LTO
object file, but isn't exported outside of the current linkage unit / DSO,
so it does not need to be exported publicly. Unfortunately IIRC this can't
be expressed in the "old" LTO API that is expose in the C interface /
libLTO.

Now for cases where we *already* have unnamed_addr (i.e. not only
local_unnamed_addr) in the IR like here, we should be able to use this
information regardless of the linker resolutions (I think), at least to
generate auto-hide.

Best,

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/4b424a4e/attachment.html>