search for: deadstrip

Hi, Can we add deadStrip() to undefinedAtoms as well ? This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. Also I think it will be cleaner for atoms to be added to deadStripRoot set using a single API. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc....

On Aug 26, 2013, at 10:20 PM, Shankar Easwaran wrote: > Can we add deadStrip() to undefinedAtoms as well ? > > This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. > > Also I think it will be cleaner for atoms to be added to deadStripRoot set using a single API. Can you give more more background on this? W...

Hi Nick, On 8/27/2013 12:45 AM, Nick Kledzik wrote: > On Aug 26, 2013, at 10:20 PM, Shankar Easwaran wrote: >> Can we add deadStrip() to undefinedAtoms as well ? >> >> This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. >> >> Also I think it will be cleaner for atoms to be added to deadStripRoot set using a single API. > Can you give more more back...

Hi Nick, Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots) 2) Or, uses a list of names that are dead strip roots (other types) Question:- *********** How are the dead strip root names supposed to be set ? Does each Reader need to set specific information on what are the dead strip roots ? There is a flag in the DefinedAtom to determine whether to...

...t 10:31 AM, Shankar Easwaran wrote: > Hi Nick, > > Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by > > 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots) > 2) Or, uses a list of names that are dead strip roots (other types) > > Question:- > *********** > How are the dead strip root names supposed to be set ? Does each Reader need to set specific information on what are the dead strip roots ? On darwin there are two mechanisms:...

Hi Nick, >> b) Further looking, there is a compiler attribute __attribute(used)__ which could be set for each symbol, but this is only a compiler hint. The information is not passed in the symbol table. If this is not passed in the symbol table to the linker, why is it in the DefinedAtom ? > In mach-o it *is* passed on to the linker by the compiler. It is the N_NO_DEAD_STRIP bit in the

...Denis. None of the symbols we are looking up require the full resolver, and they are all special linker symbols. I propose two things. 1. Provide a hook as per what Shankar suggested for the resolver. User references to linker defined symbols such as _GLOBAL_OFFSET_TABLE_ get created and possibly deadstripped here. The linking context owns the atom. 2. The ELFLinkingContext gains <Atom *getOrCreateLinkerDefinedAtom(StringRef);>. This can be used in passes to get the symbols. The hook in (1) would call this to create the atoms. This gives a single place where linker defined atoms are actually c...

...ols we are looking up require the full resolver, and > they are all special linker symbols. I propose two things. > > 1. Provide a hook as per what Shankar suggested for the resolver. User > references to linker defined symbols such as _GLOBAL_OFFSET_TABLE_ get > created and possibly deadstripped here. The linking context owns the > atom. > 2. The ELFLinkingContext gains <Atom > *getOrCreateLinkerDefinedAtom(StringRef);>. This can be used in passes > to get the symbols. The hook in (1) would call this to create the > atoms. > > This gives a single place where l...

+ Nick On 2/19/2015 9:00 AM, Shankar Easwaran wrote: > On 2/19/2015 3:58 AM, Denis Protivensky wrote: >> Joerg: >>> I propose to add the ability to ignore undefined symbols during initial >>> resolution, and then postprocess only those undefines for the second >>> time >>> after the pass manager execution. >> Do you want to do that before or

...VM :: LTO/X86/parallel.ll LLVM :: LTO/X86/strip-debug-info.ll LLVM :: ThinLTO/X86/cache-config.ll LLVM :: ThinLTO/X86/cache-icall.ll LLVM :: ThinLTO/X86/cache-import-lists.ll LLVM :: ThinLTO/X86/cache-typeid-resolutions.ll LLVM :: ThinLTO/X86/cache.ll LLVM :: ThinLTO/X86/deadstrip.ll LLVM :: ThinLTO/X86/debuginfo-compositetype-import.ll LLVM :: ThinLTO/X86/diagnostic-handler-remarks-with-hotness.ll LLVM :: ThinLTO/X86/diagnostic-handler-remarks.ll LLVM :: ThinLTO/X86/dicompositetype-unique-alias.ll LLVM :: ThinLTO/X86/dicompositetype-unique.ll LLVM ::...

On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >>