search for: hasavailableexternallylinkage

...johnson 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...

...t; > 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...

...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 >> >> >>> >> w...

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

...) was modified to search for a non-mapped function in all "other" modules. If found a stub is emitted, which will lazily emit the real function at runtime. One issue here is that functions that are external to all modules, have their mappings delayed by the above loop. I also kept the hasAvailableExternallyLinkage() the same as before, as I'm not sure if this should also go through the same module procedure. The stub emission will only take place for function definitions that are marked with external linkage. Should other cases be allowed? Should visibility also be considered? 3) JIT::getOrEmitGloba...

...rloading 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 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 marks any referenced global as needed. Here there was no > guard...

...ass() { return new ElimAvailExtern(); } + +bool ElimAvailExtern::runOnModule(Module &M) { + bool Changed = false; + + // Drop initializers of available externally global variables. + for (Module::global_iterator I = M.global_begin(), E = M.global_end(); + I != E; ++I) { + if (!I->hasAvailableExternallyLinkage()) + continue; + if (I->hasInitializer()) { + Constant *Init = I->getInitializer(); + I->setInitializer(nullptr); + if (isSafeToDestroyConstant(Init)) + Init->destroyConstant(); + } + I->removeDeadConstantUsers(); + NumVariables++; + } + + //...

..., 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 >>>>>>&g...

...;other" modules. If found a stub is emitted in the same manner as other in module functions found. This stub gets re-emitted, toward the end of the JIT cycle. One issue here is that functions that are external to all modules, have their mappings delayed by the above loop. I also kept the hasAvailableExternallyLinkage() the same as before, as I'm not sure if this should also go through the same module procedure. The stub emission will only take place for function definitions that are marked with external linkage. Should other cases be allowed? Should visibility also be considered? 3) JIT::getOrEmitGloba...

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

On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com> wrote: >> >> Agreed. Although I assume you mean invoke the new pass under a >> ThinLTO-only option so that avail extern are not dropped in the >> compile pass before the LTO link? > > > No, this pass

...found a stub is emitted in the same manner as other in module functions > found. This stub gets re-emitted, > toward the end of the JIT cycle. > > One issue here is that functions that are external to all modules, have > their mappings delayed by the > above loop. I also kept the hasAvailableExternallyLinkage() the same as > before, as I'm not sure if this > should also go through the same module procedure. The stub emission will > only take place for function > definitions that are marked with external linkage. Should other cases be > allowed? Should visibility also > be considere...

Hi all, First post to the list, I hope you can help or guide me on this task. I am involved in a project that requires to re-link extracted and edited IR code Thus I want to know if these tools can be used in this way? clang++-4.0 code03.cpp -emit-llvm -S -o code03.ll llvm-extract-4.0 code03.ll -func main -S -o extracted_main.ll llvm-link-4.0 code03.ll -only-needed -override extracted_main.ll

...non-mapped > function in all "other" modules. > If found a stub is emitted, which will lazily emit the real function at > runtime. > > One issue here is that functions that are external to all modules, have > their mappings delayed by the > above loop. I also kept the hasAvailableExternallyLinkage() the same as > before, as I'm not sure if this > should also go through the same module procedure. The stub emission will > only take place for function > definitions that are marked with external linkage. Should other cases be > allowed? Should visibility also > be considere...

...ck into the JITEmitter. If you add a "Function*findDefiningFunction(Function*)" method to the JIT, which searches the Modules for the strongest definition of a same-named function, you can keep the logic for how to deal with compiling that function in the JITEmitter. > I also kept the hasAvailableExternallyLinkage() the same as > before, as I'm not sure if this > should also go through the same module procedure. If something's available_externally in the current module and external in another module, I think we should compile the external definition. If it's available_externally in all mod...

...ser::op_iterator U = I->op_begin(), E = I->op_end(); U != E; ++U) >> - if (GlobalValue *GV = dyn_cast<GlobalValue>(*U)) >> - GlobalIsNeeded(GV); >> + if (GlobalValue *GV = dyn_cast<GlobalValue>(*U)) { >> + if (!GV->hasAvailableExternallyLinkage()) >> + GlobalIsNeeded(GV); >> + } >> else if (Constant *C = dyn_cast<Constant>(*U)) >> MarkUsedGlobalsAsNeeded(C); >> } > > > IIUC, this changes the logic from "if it's referenced, keep it" to...

...ill update the comment. > > + MPM.add(createElimAvailExternPass()); > + } > > + // Drop initializers of available externally global variables. > + for (Module::global_iterator I = M.global_begin(), E = M.global_end(); > + I != E; ++I) { > + if (!I->hasAvailableExternallyLinkage()) > + continue; > + if (I->hasInitializer()) { > + Constant *Init = I->getInitializer(); > + I->setInitializer(nullptr); > + if (isSafeToDestroyConstant(Init)) > + Init->destroyConstant(); > + } > + I->removeDeadConstantUse...

...gt; "Function*findDefiningFunction(Function*)" method to the JIT, which > searches the Modules for the strongest definition of a same-named > function, you can keep the logic for how to deal with compiling that > function in the JITEmitter. Will do > >> I also kept the hasAvailableExternallyLinkage() the same as >> before, as I'm not sure if this >> should also go through the same module procedure. > > If something's available_externally in the current module and external > in another module, I think we should compile the external definition. > If it's ava...

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take