search for: modulelink

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

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

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

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

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

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

...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)) { >...

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

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

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

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

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

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

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

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

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

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

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

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

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