search for: modulelink

Displaying 20 results from an estimated 57 matches for "modulelink".

2006 Jan 12
16
master detail problem
...:action => ''show'', :id => @moduleunit %> | <%= link_to ''Back'', :action => ''list'' %> where moduleunit is the primamry key of the parent table. This loads the linkform partial( is that correct? ) which contains this: <% for modulelink in @moduleunit.modulelinks %> <tr><td class="altcolor">Link Anchor</td><td><input type="text" name="modulelink[linkAnchor<%= modulelink.id %>]" value="<%= modulelink.linkAnchor%>"/></td></tr> <tr&g...
2011 Aug 04
2
[LLVMdev] metadata linking bug or by design
I looked at an earlier version. NamedMDNodes were linked after global values. Current trunk version links NamedMDNodes before that, though the comment says otherwise: "We do this after linking GlobalValues so that MDNodes that reference GlobalValues are properly remapped". see ModuleLinker::run in lib/Linker/LinkModules.cpp. If I move the call to linkNamedMDNodes in ModuleLinker::run to the last step (just before return false), everything looks good. Not sure if linkNamedMDNodes must be called earlier. - xi On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <dpatel at apple.com&gt...
2017 Jun 19
2
JIT, LTO and @llvm.global_ctors: Looking for advise
...he @llvm.global_ctors and @llvm.global_dtors references from the linked-in modules to be discarded :-(. AFAICT, the Linker code assumes ThinLTO when the LinkOnlyNeeded flags is specified, and full-LTO otherwise. To resolve this, we have locally patched llvm/lib/Linker/LinkModules.cpp with: bool ModuleLinker::run() { // .... if (shouldImportIntrinsicGlobalVariables()) { auto addIntrinsicGlobalVariable = [ValuesToLink, srcM](llvm::StringRef name) { if (GlobalValue *GV = SrcM->getGlobalVariable(name)) { ValuesToLink.insert(GV...
2011 Aug 04
0
[LLVMdev] metadata linking bug or by design
...an earlier version. NamedMDNodes were linked after global > values. Current trunk version links NamedMDNodes before that, though > the comment says otherwise: "We do this after linking GlobalValues so > that MDNodes that reference GlobalValues are properly remapped". see > ModuleLinker::run in lib/Linker/LinkModules.cpp. > > If I move the call to linkNamedMDNodes in ModuleLinker::run to the > last step (just before return false), everything looks good. Not sure > if linkNamedMDNodes must be called earlier. I made that change in response to Chris's change Val...
2011 Nov 04
3
[LLVMdev] Problems with lazy linking change
r143524 changed ModuleLinker such that when linking a Module B into a Module A, any internal/private/... functions in B are only linked into A if there is a use of them in A. This is problematic for my usage of module linking, where I'm basically linking a few modules together (some of which include internal functions)...
2012 Jan 11
2
[LLVMdev] ValueMapper question: no type mapping for GlobalValue?
Hi all, I was looking at the ValueMapper code this morning and I notice that it doesn't do type mapping for GlobalValues. Is this correct? I ask because I am seeing a case where I'm failing type assertions from ModuleLinker::linkGlobalInits() when an array initializer references an external global. It looks like the external global is being mapped directly and this causes an element type check to fail in ConstantArray::get(). Curiously, this only happens when that external global is also referenced from within a fu...
2017 Jun 20
2
JIT, LTO and @llvm.global_ctors: Looking for advise
...global_dtors references from the >linked-in modules to be discarded :-(. AFAICT, the Linker code assumes >ThinLTO when the LinkOnlyNeeded flags is specified, and full-LTO >otherwise. > >To resolve this, we have locally patched >llvm/lib/Linker/LinkModules.cpp with: > > bool ModuleLinker::run() { > > // .... > > if (shouldImportIntrinsicGlobalVariables()) { > auto addIntrinsicGlobalVariable = [ValuesToLink, > srcM](llvm::StringRef name) { > if (GlobalValue *GV = SrcM->getGlobalVariable(name)) { >...
2011 Nov 04
0
[LLVMdev] Problems with lazy linking change
On Fri, Nov 4, 2011 at 10:46 AM, Matt Pharr <matt.pharr at gmail.com> wrote: > r143524 changed ModuleLinker such that when linking a Module B into a Module A, any internal/private/... functions in B are only linked into A if there is a use of them in A.  This is problematic for my usage of module linking, where I'm basically linking a few modules together (some of which include internal functions)...
2012 Jan 12
0
[LLVMdev] ValueMapper question: no type mapping for GlobalValue?
On 11/01/12 07:50 AM, Michael Muller wrote: > > Hi all, I was looking at the ValueMapper code this morning and I notice that > it doesn't do type mapping for GlobalValues. Is this correct? > > I ask because I am seeing a case where I'm failing type assertions from > ModuleLinker::linkGlobalInits() when an array initializer references an > external global. It looks like the external global is being mapped directly > and this causes an element type check to fail in ConstantArray::get(). > Curiously, this only happens when that external global is also referenced f...
2011 Aug 04
0
[LLVMdev] metadata linking bug or by design
On Aug 4, 2011, at 8:21 AM, Xi Wang wrote: > Hi, > > It seems that current linker "drops" updated llvm::Value * references > in metadata. Here goes an example. We have a two-line source file > a.c: > > static int x; > void foo() { x = 1; } > > and a similar b.c: > > static int x; > void bar() { x = 1; } > > They both have an internal
2015 Jul 31
1
[LLVMdev] The Trouble with Triples
...ep, that all makes sense to me. The user/driver would be responsible for ensuring each tool is called with the same options, while each tool is responsible for using the same TargetTuple in all its calls to LLVM. The only bit I'm unsure about w.r.t to not having a serialization in the IR is the ModuleLinker where we currently have code to ensure that all the modules are compatible (by comparing the triple). Presumably, this code was added because there was a real possibility of having incompatible modules (i.e. different triples) so we shouldn't rely on the tool options here. For this the serial...
2015 May 13
10
[LLVMdev] RFC: ThinLTO Impementation Plan
...ion to import and its index into bitcode reader. - Marking of imported functions (for use in ThinLTO-specific symbol linking and global DCE, for example). This can be in-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 functions changes to AvailableExternallyLinkage, for example. Statics must be promoted in certain cases, and renamed in consistent ways. - GlobalDCE changes to support removing importe...
2016 Apr 20
2
Lazily Loaded Modules and Linker::LinkOnlyNeeded
...ran afterwards ripping out functions that weren't used. So I tried it, and it failed. Basically any function that was still to be materialized wasn't getting its body copied over during linking. The only line of code that differs when you set LinkOnlyNeeded is in LinkModules.cpp -> ModuleLinker::linkIfNeeded: if (shouldLinkOnlyNeeded() && !(DGV && DGV->isDeclaration())) return false; The isDeclaration() for functions has a call to isMaterializable(). Things I've tried: * If I don't pass LinkOnlyNeeded but still link from the lazily loaded runti...
2017 Jun 20
2
JIT, LTO and @llvm.global_ctors: Looking for advise
...>>linked-in modules to be discarded :-(. AFAICT, the Linker code assumes >>ThinLTO when the LinkOnlyNeeded flags is specified, and full-LTO >>otherwise. >> >>To resolve this, we have locally patched >>llvm/lib/Linker/LinkModules.cpp with: >> >> bool ModuleLinker::run() { >> >> // .... >> >> if (shouldImportIntrinsicGlobalVariables()) { >> auto addIntrinsicGlobalVariable = [ValuesToLink, >> srcM](llvm::StringRef name) { >> if (GlobalValue *GV = SrcM->get...
2011 Aug 04
2
[LLVMdev] metadata linking bug or by design
Hi, It seems that current linker "drops" updated llvm::Value * references in metadata. Here goes an example. We have a two-line source file a.c: static int x; void foo() { x = 1; } and a similar b.c: static int x; void bar() { x = 1; } They both have an internal variable x; one of them will be renamed (to x1) during linking. clang -emit-llvm -c -g a.c clang -emit-llvm -c -g b.c
2015 Jul 31
0
[LLVMdev] The Trouble with Triples
...ep, that all makes sense to me. The user/driver would be responsible for ensuring each tool is called with the same options, while each tool is responsible for using the same TargetTuple in all its calls to LLVM. The only bit I'm unsure about w.r.t to not having a serialization in the IR is the ModuleLinker where we currently have code to ensure that all the modules are compatible (by comparing the triple). Presumably, this code was added because there was a real possibility of having incompatible modules (i.e. different triples) so we shouldn't rely on the tool options here. For this the serial...
2015 May 14
2
[LLVMdev] RFC: ThinLTO Impementation Plan
...- Marking of imported functions (for use in ThinLTO-specific symbol > > linking and global DCE, for example). This can be in-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 > > functions changes to AvailableExternallyLinkage, for example. Statics > > must be promoted in certain cases, and renamed in consistent ways. > > > &gt...
2014 Jul 31
2
[LLVMdev] Inconsistent third field in global_ctors (was Re: [llvm] r214321 - UseListOrder: Visit global values)
...particular, I don't think the auto-upgrade is actually buying us anything. I guess the "right" fix might be to make these global arrays first-class IR objects, but even if we had the right design, it's not clear how to upgrade to *that*. The main complication with (1) is getting ModuleLinker to do the right thing -- I think I can just move the canonicalization code there, and only trigger it if the constructor styles don't match between the two modules. AFAICT, it's doing the wrong thing right now if the modules aren't read from bitcode, so this is probably necessary any...
2015 May 15
3
[LLVMdev] RFC: ThinLTO Impementation Plan
.... after all function > >>> importing is complete). This actually applies to all module-level > >>> metadata, not just debug, although it is the largest. This can be > >>> added as a separate set of patches. Changes to BitcodeReader, > >>> ValueMapper, ModuleLinker > >> > >> It sounds like this would work well with the "full" LTO implemented > >> by tools/gold-plugin right now. What exactly did you do to improve > >> this? > > > > I don't think it will help with full LTO. The parsing of the meta...
2015 May 14
2
[LLVMdev] RFC: ThinLTO Impementation Plan
...ThinLTO-specific symbol > >> > linking and global DCE, for example). This can be in-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 > >> > functions changes to AvailableExternallyLinkage, for example. Statics > >> > must be promoted in certain cases, and renamed in consiste...