search for: availableexternallylinkage

Hi, could anybody explain what GlobalValue::AvailableExternallyLinkage means? I implemented an instrumentation pass that creates a clone of a function. For some programs I noticed that also function such as “atoi”, “atof”, “__strspn_c2”, etc. they get cloned even if I am not implementing them in the module. I would like to avoid cloning those functions, so I noticed...

...zer instrumentation pass only on the new copy of the functions, i.e. only the “_parallel” functions will be instrumented by tsan. In some programs that I am compiling, the functions such as atoi and atof get cloned but I want to avoid this, and I noticed that only those functions have GlobalValue::AvailableExternallyLinkage, so I was wondering if checking the linkage is enough to avoid those library functions or there could be situations of functions with that linkage but that have the body implemented in the same module. Does it make sense now? Thanks. Simone > On Nov 19, 2016, at 13:32, Mehdi Amini <mehdi....

...n pass only on the new copy of the functions, i.e. only the “_parallel” functions will be instrumented by tsan. >> >> In some programs that I am compiling, the functions such as atoi and atof get cloned but I want to avoid this, and I noticed that only those functions have GlobalValue::AvailableExternallyLinkage, so I was wondering if checking the linkage is enough to avoid those library functions or there could be situations of functions with that linkage but that have the body implemented in the same module. >> >> Does it make sense now? > > That gives me more context yes, now the qu...

...he new copy of the functions, i.e. only the “_parallel” functions will be instrumented by tsan. >>>> >>>> In some programs that I am compiling, the functions such as atoi and atof get cloned but I want to avoid this, and I noticed that only those functions have GlobalValue::AvailableExternallyLinkage, so I was wondering if checking the linkage is enough to avoid those library functions or there could be situations of functions with that linkage but that have the body implemented in the same module. >>>> >>>> Does it make sense now? >>> >>> That gives...

...the imported copy. 2.2 Linkage Effects There is no change to the linkage type required in the original module for any non-discardable values that may be imported to another module. During importing, ideally all non-discardable definitions have their linkage type changed in the imported copy to AvailableExternallyLinkage. This signals to the compiler that the definition can safely be eliminated after inlining (i.e. by the new EliminateAvailableExternally pass). In practice, we do not change the linkage for all imported non-discardable defs. The linkage effects for the non-discardable linkage types are described bel...

...gt; > > There is no change to the linkage type required in the original module > for any non-discardable values that may be imported to another module. > > > > During importing, ideally all non-discardable definitions have their > linkage type changed in the imported copy to AvailableExternallyLinkage. > This signals to the compiler that the definition can safely be eliminated > after inlining (i.e. by the new EliminateAvailableExternally pass). In > practice, we do not change the linkage for all imported non-discardable > defs. The linkage effects for the non-discardable linkage typ...

An enumeration for the kinds of linkage for global values. Hi, I'm currently writing a compiler that takes llvm-ir input. I'm a little confused by the following linkage flags: Enumerator: > > ExternalLinkage: Externally visible function > > AvailableExternallyLinkage: Available for inspection, not emission. > > LinkOnceAnyLinkage: Keep one copy of function when linking (inline) > > LinkOnceODRLinkage: Same, but only replaced by something equivalent. > > WeakAnyLinkage: Keep one copy of named function when linking (weak) > > WeakODRLinkag...

On Fri, May 15, 2015 at 9:18 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> - Marking of imported functions (for use in ThinLTO-specific symbol >> >> linking and global DCE, for example). >> > >> > Marking how? Do you mean giving them internal linkage, or something >> > else? >> >> Mentioned just after this: either

...ay or may > not be > > useful to split some of these subthreads into separate email threads to > keep > > discussion clear - but I'm not sure) > > I just went back and looked at my prototype and I had remembered this > wrong. An imported function is always marked > AvailableExternallyLinkage, unless it has link once linkage. > > As far as using that to indicate that it is an aux function, I was > concerned about overloading the meaning of that linkage type. See the > next para for an example where I am unsure about doing this... > > Looking back through my GlobalDCE c...

...n-memory initially, but IR support may be required in order to support streaming bitcode out and back in again after importing. * ModuleLinker changes to do ThinLTO-specific symbol linking and static promotion when necessary. The linkage type of imported non-local functions and variables changes to AvailableExternallyLinkage, for example. Statics must be promoted in certain cases, and accordingly renamed in consistent ways. Read-write or address-taken static variables must always be promoted. Other discardable functions, i.e. link-once such as comdats, will be force imported on reference by another imported function. W...

...nson at google.com> >>> > wrote: >>> >> >>> >> Looking back through my GlobalDCE changes, it looks like one of the >>> >> places I had changed (where we mark defined globals in runOnModule) >>> >> already has a guard for !hasAvailableExternallyLinkage and >>> >> !isDiscardableIfUnused, so my additional guard against marking >>> >> imported functions is unnecessary. But the other place I had to change >>> >> was in GlobalIsNeeded where it walks through the function and >>> >> recursively...

...R support may be required in order to > support streaming bitcode out and back in again after importing. > * ModuleLinker changes to do ThinLTO-specific symbol linking and > static promotion when necessary. The linkage type of imported > non-local functions and variables changes to > AvailableExternallyLinkage, for example. Statics must be promoted in > certain cases, and accordingly renamed in consistent ways. Read-write > or address-taken static variables must always be promoted. Other > discardable functions, i.e. link-once such as comdats, will be force > imported on reference by another...

...uired in order to >> support streaming bitcode out and back in again after importing. >> * ModuleLinker changes to do ThinLTO-specific symbol linking and >> static promotion when necessary. The linkage type of imported >> non-local functions and variables changes to >> AvailableExternallyLinkage, for example. Statics must be promoted in >> certain cases, and accordingly renamed in consistent ways. Read-write >> or address-taken static variables must always be promoted. Other >> discardable functions, i.e. link-once such as comdats, will be force >> imported on refer...

...code out and back in again after importing. >>>>> * ModuleLinker changes to do ThinLTO-specific symbol linking and >>>>> static promotion when necessary. The linkage type of imported >>>>> non-local functions and variables changes to >>>>> AvailableExternallyLinkage, for example. Statics must be promoted in >>>>> certain cases, and accordingly renamed in consistent ways. Read-write >>>>> or address-taken static variables must always be promoted. Other >>>>> discardable functions, i.e. link-once such as comdats, will...

...GlobalDCE changes, it looks like one of >> >> >>> >> the >> >> >>> >> places I had changed (where we mark defined globals in >> >> >>> >> runOnModule) >> >> >>> >> already has a guard for !hasAvailableExternallyLinkage and >> >> >>> >> !isDiscardableIfUnused, so my additional guard against marking >> >> >>> >> imported functions is unnecessary. But the other place I had to >> >> >>> >> change >> >> >>> >> w...

...in order to > > support streaming bitcode out and back in again after importing. > > * ModuleLinker changes to do ThinLTO-specific symbol linking and > > static promotion when necessary. The linkage type of imported > > non-local functions and variables changes to > > AvailableExternallyLinkage, for example. Statics must be promoted in > > certain cases, and accordingly renamed in consistent ways. Read-write > > or address-taken static variables must always be promoted. Other > > discardable functions, i.e. link-once such as comdats, will be force > > imported on r...

...t;> support streaming bitcode out and back in again after importing. > >> * ModuleLinker changes to do ThinLTO-specific symbol linking and > >> static promotion when necessary. The linkage type of imported > >> non-local functions and variables changes to > >> AvailableExternallyLinkage, for example. Statics must be promoted in > >> certain cases, and accordingly renamed in consistent ways. Read-write > >> or address-taken static variables must always be promoted. Other > >> discardable functions, i.e. link-once such as comdats, will be force > >&g...

...> wrote: >> >>> >> >> >>> >> Looking back through my GlobalDCE changes, it looks like one of the >> >>> >> places I had changed (where we mark defined globals in runOnModule) >> >>> >> already has a guard for !hasAvailableExternallyLinkage and >> >>> >> !isDiscardableIfUnused, so my additional guard against marking >> >>> >> imported functions is unnecessary. But the other place I had to >> >>> >> change >> >>> >> was in GlobalIsNeeded where it walks...

...rt streaming bitcode out and back in again after importing. >>>> * ModuleLinker changes to do ThinLTO-specific symbol linking and >>>> static promotion when necessary. The linkage type of imported >>>> non-local functions and variables changes to >>>> AvailableExternallyLinkage, for example. Statics must be promoted in >>>> certain cases, and accordingly renamed in consistent ways. Read-write >>>> or address-taken static variables must always be promoted. Other >>>> discardable functions, i.e. link-once such as comdats, will be force &g...

...; > support streaming bitcode out and back in again after importing. >> > * ModuleLinker changes to do ThinLTO-specific symbol linking and >> > static promotion when necessary. The linkage type of imported >> > non-local functions and variables changes to >> > AvailableExternallyLinkage, for example. Statics must be promoted in >> > certain cases, and accordingly renamed in consistent ways. Read-write >> > or address-taken static variables must always be promoted. Other >> > discardable functions, i.e. link-once such as comdats, will be force >> &g...