search for: linkinmodule

...eamE = type { %class.RecordStream }</div><div>    declare extern_weak void @_EN12RecordStream4InitEPTsN18_EN12RecordStreamEEPvv(%struct._EN12RecordStreamE*, i8*)</div><div>   </div><div>    ... But later I'm not able to link in ModuleB to ModuleA using linker.linkInModule(std::move(ModuleB));</div><div>    llvm says: Assertion failed: !(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type",...</div><div> </div><div>    Could someone point me what conceptually I did wrong?</div>

...is the `IRUnitT` type? Or rather, how should I be creating the `PassManager`? Why does `EngineBuilder` require a `unique_ptr` for the `Module` now? After I create the builder I still need to reference the module, in particular to run the pass manager and look up functions to run. Same for `linker::linkInModule`. `createBasicAliasAnalyisPass` is gone. What is the replacement, or do I not need it anymore (I believe it was required to be run for other passes). `linkInModule` used to provide an error message output. Is there a way to get the error now that it is gone? -- edA-qa mort-ora-y http://mortora...

If I create a function in a module with: auto f = module->getOrInsertFunction( "eval_expr", ...) //create function Then later I link this with other modules: Linker link; link.LinkInModule( base_module ); link.LinkInModule( module ); Then I create an execution engine something like: auto ee = EngineBuilder( link.getModule() )...create(); If I attempt to run the function directly I get an error: ee->runFunction( f, args ); "LLVM ERROR: Program used external function '...

...", currentBB); Finally, i do CallInst::Create(fooFunction, args_vector, "", currentBB); Everything seems to be fine so far. Now i link two modules together and run Verifier: llvm::Linker linker("myModule", runtimeModule); linker.LinkInModule(myModule, &err); llvm::verifyModule(*linker.releaseModule()); This gives me error: Call parameter type does not match function signature! %"arg1" = alloca %type %"type 0x801e9b550"* %0 = call i32 @foo(%type* %"~3", %type* %"arg2", %type* %"arg3&...

...cause IRMover tries to map the metadata that already mapped in the destination module, and it seems that this happens because two different IRMovers are used for the same destination (or composite) module. During LTO, an IRMover is created in thinLTOBackendTask function(tools/gold/gold-plugin.cpp). linkInModule function, which is called by thinLTOBackendTask, calls the ‘move’ function of this IRMover. The other IRMover is created when “TheLinker” is created in FunctionImporter::importFunctions (lib/Transforms/IPO/FunctionImport.cpp). thinLTOBackendTask invokes FunctionImporeter::importFunctions as well, w...

...oaded. We are currently using the MCJIT API, but are planning to move to ORC very soon. Our LLVM module linking code goes roughly as follows: Linker linker(jittedModule); std::unique_ptr<llvm::Module> moduleToLink( getLazyIRFileModule(bcFileName, error, context)); linker.linkInModule(std::move(module), Linker::LinkOnlyNeeded | Linker::InternalizeLinkedSymbol); Our issue is with the Linker::LinkOnlyNeeded flag. Using it has a huge positive impact on link and compilation time :-). But, it causes the @llvm.global_ctors and @llvm.global_...

On Fri, May 15, 2015 at 12:02 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-May-15, at 07:30, Teresa Johnson <tejohnson at google.com> wrote: > > > >>> a. Lazy Debug Metadata Linking: > >>> > >>> The prototype implementation included lazy importing of module-level > >>> metadata during the

...e::ExternalLinkage, init, "my_global_var" ); Linker *linker = new Linker("linker-name", "main-module", context, 0); string errMsg; linker->LinkInModule(mod1, &errMsg); Module *mod2 = new Module("second", context); GlobalVariable *refGVar = new GlobalVariable(*mod2, type->getPointerTo(), false, GlobalValue::ExternalLinkage, gvar, &quot...

...00000006da65d 13 llvm-ld 0x00000000006da65d 14 llvm-ld 0x00000000006daade 15 llvm-ld 0x00000000006dac98 16 llvm-ld 0x00000000006de6d9 llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::string*) + 1897 17 llvm-ld 0x00000000006d8a7d llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 41 18 llvm-ld 0x00000000006d7ff3 llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) + 1431 19 llvm-ld 0x00000000006d867e llvm::Linker::LinkInItems(std::vector<std::pair<std::string, bool>, std::allocator<std::pair<std::str...

=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?= wrote: > > I can reproduce this consistently, but only under an extremely large pile of > > code :-) I haven't tried to strip it down to minimal a test case yet, but I > > will. One salient difference with the code you've provided is that in my > > code, @a is a struct type. However, changing the example to use a

...ng the MCJIT API, but are planning to move to ORC > very soon. > >Our LLVM module linking code goes roughly as follows: > > Linker linker(jittedModule); > std::unique_ptr<llvm::Module> moduleToLink( > getLazyIRFileModule(bcFileName, error, context)); > linker.linkInModule(std::move(module), > Linker::LinkOnlyNeeded | > Linker::InternalizeLinkedSymbol); > >Our issue is with the Linker::LinkOnlyNeeded flag. Using it has a huge >positive impact on link and compilation time :-). But, it causes the >@llvm.global...

...lvm::GlobalAlias::getOperand(unsigned int) const + 70 10 llvm-ld 0x083de0d1 llvm::GlobalAlias::getAliasee() + 37 11 llvm-ld 0x083dc3c6 12 llvm-ld 0x083dcdb5 13 llvm-ld 0x083dce74 llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::string*) + 64 14 llvm-ld 0x083d949a llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 46 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) + 1524 16 llvm-ld 0x083d943d llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > const&) + 67 17 llvm-ld 0x083ad740 main...

...alueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #13 0x00007ffff3755786 in (anonymous namespace)::ModuleLinker::linkGlobalValueBody(llvm::GlobalValue&) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #14 0x00007ffff375767f in llvm::Linker::linkInModule(llvm::Module*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #15 0x00007ffff3758cfb in llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::function<void (llvm::DiagnosticInfo const&)>) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #16 0x00007ffff6c9d8cf in clang::Bac...

...e LTO starts with an empty module, so when you move the first module into the "merged module”, the map gets initialized. In ThinLTO the mover starts with the destination module not empty. — Mehdi During LTO, an IRMover is created in thinLTOBackendTask function(tools/gold/gold-plugin.cpp). linkInModule function, which is called by thinLTOBackendTask, calls the ‘move’ function of this IRMover. The other IRMover is created when “TheLinker” is created in FunctionImporter::importFunctions (lib/Transforms/IPO/FunctionImport.cpp). thinLTOBackendTask invokes FunctionImporeter::importFunctions as well, w...

...ilation works fine, but at runtime, I encounter the following assertion: Assertion failed: FunctionType::isValidReturnType(getReturnType()) && !isa<OpaqueType>(getReturnType ()) && "invalid return type", file .\Function.cpp, line 164 This happens somewhere in "LinkInModule" when trying to link two loaded .bc-files (generated by llvm-g++). The weird point: The assertion fires because the comparison RetTy == Type::VoidTy in isValidReturnType() fails although the TypeID is 0, the printed type is "void" and the function actually *does* return void. This d...

...    currentBB); > > Finally, i do > > CallInst::Create(fooFunction, args_vector, "", currentBB); > > Everything seems to be fine so far. > Now i link two modules together and run Verifier: > > llvm::Linker linker("myModule", runtimeModule); > linker.LinkInModule(myModule, &err); > llvm::verifyModule(*linker.releaseModule()); > > This gives me error: > Call parameter type does not match function signature! >   %"arg1" = alloca %type >  %"type 0x801e9b550"*  %0 = call i32 @foo(%type* %"~3", %type* %"ar...

...nsigned int) const + 70 > 10 llvm-ld 0x083de0d1 llvm::GlobalAlias::getAliasee() + 37 > 11 llvm-ld 0x083dc3c6 > 12 llvm-ld 0x083dcdb5 > 13 llvm-ld 0x083dce74 llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, > std::string*) + 64 > 14 llvm-ld 0x083d949a llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 46 > 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) > + 1524 > 16 llvm-ld 0x083d943d llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, > std::allocator<llvm::sys::Path> > const&) + 67 > 17...

...ain program generates 'testfn' using llvm::IRBuilder (something similar to Kaleidoscope tutorial does). The 'testfn' does not have any of those attributes or MetadataNodes of course. (5) The raw bitcode data and the 'testfn' are combined into a single module using LLVM's LinkinModule API, then fed into optimizer. What do you think is the proper fix for my use case? I can think of a few, but I don't think I have enough context to determine which is the most proper fix. (1) Remove all MetadataNode and attributes from the bitcode files. Is this sufficient to prevent all weird...

...0 llvm-ld 0x083de0d1 llvm::GlobalAlias::getAliasee() + 37 > > 11 llvm-ld 0x083dc3c6 > > 12 llvm-ld 0x083dcdb5 > > 13 llvm-ld 0x083dce74 llvm::Linker::LinkModules(llvm::Module*, > llvm::Module*, > > std::string*) + 64 > > 14 llvm-ld 0x083d949a llvm::Linker::LinkInModule(llvm::Module*, > std::string*) + 46 > > 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path const&, > bool&) > > + 1524 > > 16 llvm-ld 0x083d943d > llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, > > std::allocator<llvm::sys::Path...

The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with