search for: private_extern

Steven Wu <stevenwu at apple.com> writes: > I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts > > 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden. What do those directives mean? I assume .weak_def_can_be_hidden is the "you can drop this from the symbol table", but...

...ote: > > Steven Wu <stevenwu at apple.com> writes: > >> I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts >> >> 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden. > > What do those directives mean? I assume .weak_def_can_be_hidden is the > "you can drop this from the symbol ta...

...Steven Wu <stevenwu at apple.com> writes: >> >>> I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts >>> >>> 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden. >> >> What do those directives mean? I assume .weak_def_can_be_hidden is the >> "you can drop this from t...

I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden. 2. ld64 does treat these two type of symbols differently. For example, ld64 will deduplicate all the can_be_hidden symbols to red...

Interesting. Now I understand the full picture. For MachO, linker is picking based on atoms so it picks the atom with more visibility which doesn’t have the constraint you mentioned. Let me do some more digging. Worst case I will add a different rule for MachO but it might be fine. Steven > On Feb 9, 2018, at 1:40 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: >

...evenwu at apple.com> writes: >>> >>>> I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts >>>> >>>> 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden. >>> >>> What do those directives mean? I assume .weak_def_can_be_hidden is the >>> "you can drop...

...at 09:55, Steven Wu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts > > 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden. > 2. ld64 does treat these two type of symbols differently. For example, ld64 will deduplicate all the can_be_hidden symbols t...

...< > llvm-dev at lists.llvm.org> wrote: > > > > I did a bit more digging for the auto hide problem. Here is my finding > that prevent us from doing this by default in GlobalOpts > > > > 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both > '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho > platform. There result of that is .private_extern will win so this is > essentially linkonce_odr hidden. > > 2. ld64 does treat these two type of symbols differently. For example, > ld64 will deduplicate all the can...

...BSSSection = 0; // no BSS section. ZeroFillDirective = "\t.zerofill\t"; // Uses .zerofill - SetDirective = "\t.set"; + SetDirective = "\t.set\t"; WeakRefDirective = "\t.weak_reference\t"; HiddenDirective = "\t.private_extern\t"; ProtectedDirective = NULL; I unfortunately don't have the code that died anymore (it was a couple months ago, and I'm unfortunately just now getting on this mailing list to report the issue), but it seems pretty obvious from the surrounding context to be wrong, and there'...

...- MCSA_IndirectSymbol, /// .indirect_symbol (MachO) - MCSA_Internal, /// .internal (ELF) - MCSA_LazyReference, /// .lazy_reference (MachO) - MCSA_Local, /// .local (ELF) - MCSA_NoDeadStrip, /// .no_dead_strip (MachO) - MCSA_PrivateExtern, /// .private_extern (MachO) - MCSA_Protected, /// .protected (ELF) - MCSA_Reference, /// .reference (MachO) - MCSA_Weak, /// .weak - MCSA_WeakDefinition, /// .weak_definition (MachO) - MCSA_WeakReference /// .weak_reference (MachO) + MCSA_ELF_TypeFunction, ///&lt...

...ta or Darwin. The "linker_private_weak" linkage has similar semantics to the "linker_private" linkage: it's private to the linkage unit and doesn't appear in the final linked image. Unlike the linker_private linkage, it has a "weak" definition. For example: .private_extern l_objc_msgSend_fixup_alloc .globl l_objc_msgSend_fixup_alloc .weak_definition l_objc_msgSend_fixup_alloc .section __DATA, __objc_msgrefs, coalesced .align 3 l_objc_msgSend_fixup_alloc: .quad _objc_msgSend_fixup .quad L_OBJC_METH_VAR_NAME_1 Whereas something with "linker_private" li...

On Monday 04 January 2010 05:16:40 Jeffrey Yasskin wrote: > On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > LLVM's TCO already handles mutual recursion. > > Only for fastcc functions Yes. > compiled with -tailcallopt, right? If you use the compiler, yes. > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > I believe

Hi all, LLVM CodeGen and Tools team at Apple is looking for exceptional compiler engineers. This is a great opportunity to work with many of the leaders in the LLVM community. If you are interested in this position, please send your resume / CV and relevant information to evan.cheng at apple.com Thanks, Evan Job description The Apple compiler team is seeking an engineer who is strongly

...on level differences between the vfp3 and neon versions. When I do the same with gcc 4.2 I do see differences in the generated code. Am I mistaken in expecting to see a difference in NEON and VFP instructions, is this my mistake, or is there something else going on here? thanks, -David .private_extern _FloatingPointTest .globl _FloatingPointTest .align 2 _FloatingPointTest: @ @FloatingPointTest @ BB#0: @ %entry sub sp, sp, #8 str lr, [sp, #4] str r7, [sp] mov r7, sp sub...

On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Monday 04 January 2010 03:33:06 Simon Harris wrote: >> On 04/01/2010, at 3:01 PM, Jon Harrop wrote: >> > I am certainly interested in tail calls because my HLVM project relies >> > upon LLVM's tail call elimination. However, I do not understand what tail >> > calls LLVM

Thanks for the info! Yes, the problem is certainly that the JITed code isn't registering its classes, but even after digging through all the runtime code I can't find anything that seems suitable for doing this.. The nearest function I could find was _objc_init_image, but that seems to be for win32! I assume that the way it works must be that clang creates some static data structures