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?> > 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/20171024/891f66df/attachment.html>
> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> http://llvm.org/docs/LangRef.html#linkage-types <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 <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20171024/4357ee8e/attachment-0001.html>
"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/20171024/508a597b/attachment.html>