[llvm-dev] linkonce expected behavior?

[Andrew Kelley via llvm-dev]

"weak" linkage was the solution. Thanks for the tip.

On Tue, Oct 24, 2017 at 10:01 PM, Andrew Kelley <superjoe30 at gmail.com>
wrote:

> "weak" worked on linux. I'm waiting to see if tests pass for
>
>  * MacOS: https://travis-ci.org/zig-lang/zig/jobs/292392617
>  * Windows: https://ci.appveyor.com/project/andrewrk/zig-
> d3l86/build/1.0.478
>
> I'll report back when they're done.
>
>
> On Tue, Oct 24, 2017 at 9:49 PM, Vedant Kumar <vsk at apple.com> wrote:
>
>>
>> On Oct 24, 2017, at 6:41 PM, Andrew Kelley <superjoe30 at gmail.com> wrote:
>>
>> On Tue, Oct 24, 2017 at 9:27 PM, Vedant Kumar <vsk at apple.com> wrote:
>>
>>> Unreferenced linkonce globals are allowed to be discarded.
>>>
>>>
>>> Is __udivmodti4 referenced?
>>>
>>
>>
>> It's referenced by a different .o file, but nothing within the module.
>>
>> My confusion comes from the missing direct object in the sentence.
>> Referenced by a function local to the module? Referenced by any object in
>> the linker job?
>>
>>
>> Ah I see. I read this as: "Linkonce globals which aren't referenced
>> within their module are allowed to be discarded."
>>
>> To your point here:
>>
>> Is there a linkage type that lets the linker merge functions of the same
>>> name but does not let the optimizer delete the function?
>>>
>>>
>> Does "weak" linkage work for you?
>>
>> vedant
>>
>>
>>
>>
>>>
>>> vedant
>>>
>>> On Oct 24, 2017, at 6:09 PM, Andrew Kelley via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>> http://llvm.org/docs/LangRef.html#linkage-types says:
>>>
>>> Globals with “linkonce” linkage are merged with other globals of the
>>> same name when linkage occurs. This can be used to implement some forms of
>>> inline functions, templates, or other code which must be generated in each
>>> translation unit that uses it, but where the body may be overridden with a
>>> more definitive definition later. Unreferenced linkonce globals are allowed
>>> to be discarded. Note that linkonce linkage does not actually allow the
>>> optimizer to inline the body of this function into callers because it
>>> doesn’t know if this definition of the function is the definitive
>>> definition within the program or whether it will be overridden by a
>>> stronger definition. To enable inlining and other optimizations, use
>>> “linkonce_odr” linkage.
>>>
>>> This makes me think that linkonce globals will not be optimized out of
>>> an .o file, but they can be deleted by the linker. Here's some IR I have:
>>>
>>> define linkonce i128 @__udivmodti4(i128, i128, i128*) local_unnamed_addr
>>> #0 !dbg !264 {
>>> ....
>>> }
>>>
>>> When I run:
>>>
>>> opt -O3 -S compiler_rt.ll
>>>
>>> It deletes the function. Is this expected behavior?
>>>
>>> Is there a linkage type that lets the linker merge functions of the same
>>> name but does not let the optimizer delete the function?
>>>
>>> (let me know if providing the entire .ll file would be helpful)
>>>
>>> Regards,
>>> Andrew Kelley
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171025/571d6957/attachment.html>