search for: linkitem

r172749 removed Linker/LinkArchives.cpp and Linker/LinkItems.cpp citing: This code is dead, and the "right" way to get this support is to use the platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM linker. Could someone please expand on what the "right way" is and these LTO mechanisms or where I can find...

...or gold + the gold plugin on Linux). See also: http://llvm.org/docs/LinkTimeOptimization.html http://llvm.org/docs/GoldPlugin.html - Daniel On Tue, Jan 29, 2013 at 11:31 AM, Chris Cadwallader <ccadwallader at arxan.com>wrote: > r172749 removed Linker/LinkArchives.cpp and Linker/LinkItems.cpp citing: > > This code is dead, and the "right" way to get this support is to use the > platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM > linker. > > Could someone please expand on what the "right way" is and these LTO >...

...lContext(); InitializeNativeTarget(); InitializeNativeTargetAsmPrinter(); InitializeNativeTargetAsmParser(); Linker llvm_linker (StringRef("llvm_test"), StringRef("MergedModule"), context, Linker::Verbose); if(argc >= 3){ int next_module_idx = 2; Linker::ItemList linkItems; while (next_module_idx < argc ){ bool is_native = false; linkItems.push_back(make_pair(string(argv[next_module_idx]), false)); next_module_idx++; } Linker::ItemList natives; if(llvm_linker.LinkInItems(linkItems, natives)){ cout << "Linking error! " &l...

...Context=@0x7fffffffdd90, ErrMsg=0x7fffffffd3f0) at BitcodeReader.cpp:2102 #16 0x0000000000de1b76 in llvm::Linker::LoadObject (this=0x7fffffffdc60, FN=@0x1d6a330) at Linker.cpp:106 #17 0x0000000000dd03eb in llvm::Linker::LinkInFile (this=0x7fffffffdc60, File=@0x1d6a330, is_native=@0x7fffffffd64b) at LinkItems.cpp:196 #18 0x0000000000dd07ea in llvm::Linker::LinkInFiles (this=0x7fffffffdc60, Files=std::vector of length 1, capacity 1 = {...}) at LinkItems.cpp:235 #19 0x0000000000b8a904 in main (argc=2, argv=0x7fffffffe098, env=0x7fffffffe0b0) at main.cpp:209 If I do _not_ include the following line at t...

...""), is that I'd like to have a full path name, not only the specific file name, of the original modules. As such, using someFunction->getParent()->getModuleIdentifier() in lib/Linker/LinkModules.cpp:650 did not suffice. However, I noticed that File.toString() in lib/Linker/LinkItems.cpp:150 does not yield the full path name. Could this patch (in a revised form) be added to LLVM? Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) > This will return a > ModuleProvider. Ask it for the Module and then ask the Module for its > identifier. This appro...

...000000010006cf52 in llvm::Linker::LoadObject (this=0x7fff5fbfcd50, FN=@0x101801a28) at /Users/talin/Projects/llvm/lib/Linker/Linker.cpp:107 #12 0x000000010006494e in llvm::Linker::LinkInFile (this=0x7fff5fbfcd50, File=@0x101801a28, is_native=@0x7fff5fbfcb7f) at /Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:199 #13 0x0000000100064c5e in llvm::Linker::LinkInFiles (this=0x7fff5fbfcd50, Files=@0x7fff5fbfce30) at /Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:238 #14 0x0000000100007c1f in main (argc=130, argv=0x7fff5fbfd1f0, envp=0x7fff5fbfd608) at /Users/talin/Projects/llvm/tools/llvm-ld/llvm-l...

On Jul 26, 2011, at 8:11 AM, Talin wrote: >> >> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level. > > I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, GEP into them, need their size, etc. > > Let me try with

...llvm-3.0.src/lib/ExecutionEngine/RuntimeDyld' make[2]: Leaving directory `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine' make[2]: Entering directory `/mnt/EXT/00/llvm/work/src/llvm-3.0. src/lib/Linker' llvm[2]: Compiling LinkArchives.cpp for Release build llvm[2]: Compiling LinkItems.cpp for Release build llvm[2]: Compiling LinkModules.cpp for Release build llvm[2]: Compiling Linker.cpp for Release build llvm[2]: Building Release Archive Library libLLVMLinker.a make[2]: Leaving directory `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/Linker' make[2]: Entering directory `/mnt/...

...ne/RuntimeDyld' > make[2]: Leaving directory > `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine' > make[2]: Entering directory `/mnt/EXT/00/llvm/work/src/llvm-3.0. > src/lib/Linker' > llvm[2]: Compiling LinkArchives.cpp for Release build > llvm[2]: Compiling LinkItems.cpp for Release build > llvm[2]: Compiling LinkModules.cpp for Release build > llvm[2]: Compiling Linker.cpp for Release build > llvm[2]: Building Release Archive Library libLLVMLinker.a > make[2]: Leaving directory `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/Linker' > make[2]:...

...make[2]: Leaving directory > > `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine' > > make[2]: Entering directory `/mnt/EXT/00/llvm/work/src/llvm-3.0. > > src/lib/Linker' > > llvm[2]: Compiling LinkArchives.cpp for Release build > > llvm[2]: Compiling LinkItems.cpp for Release build > > llvm[2]: Compiling LinkModules.cpp for Release build > > llvm[2]: Compiling Linker.cpp for Release build > > llvm[2]: Building Release Archive Library libLLVMLinker.a > > make[2]: Leaving directory `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/Linker...

Hi Bram, On Sun, 2006-09-24 at 22:58 +0200, Bram Adams wrote: > Hi, > > During link-time optimization using llvm-ld, I occasionally need to > find the name/ID of the original module/bytecode file a Function > belonged to. In order to do this I added a nameOfPreviousModule- > attribute to Function and some getters/setters (see attached patch). > However, I can't

...gt; I'd like to have a full path name, not only the specific file name, of the > original modules. As such, using > someFunction->getParent()->getModuleIdentifier() in > lib/Linker/LinkModules.cpp:650 did not suffice. However, I noticed that > File.toString() in lib/Linker/LinkItems.cpp:150 does not yield the full path > name. > > Could this patch (in a revised form) be added to LLVM? What are you trying to accomplish? Why not use location records from debug info? -Chris -- http://nondot.org/sabre/ http://llvm.org/

Hi, During link-time optimization using llvm-ld, I occasionally need to find the name/ID of the original module/bytecode file a Function belonged to. In order to do this I added a nameOfPreviousModule- attribute to Function and some getters/setters (see attached patch). However, I can't find out how to read in the ModuleID of a Module during bytecode loading in

...n debian. > I use cfrontend-1.5.i686-redhat-linux-gnu.tar.gz to be compiled on > debian.But there is something wrong . > the detail is below: > make[2]: Entering directory `/home/fpeng/llvm/lib/Linker' > llvm[2]: Compiling LinkArchives.cpp for Debug build > llvm[2]: Compiling LinkItems.cpp for Debug build > llvm[2]: Compiling LinkModules.cpp for Debug build > llvm[2]: Compiling Linker.cpp for Debug build > llvm[2]: Building Debug Archive Library libLLVMLinker.a > make[2]: Leaving directory `/home/fpeng/llvm/lib/Linker' > make[1]: Target `all' not remade be...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached