search for: ltocodegenerator

...#39;t find anything and > my fresh checkout should have failed as well. Any suggestions as to what I could > have done wrong? FWIW, I am getting the same linker errors on OS X: Undefined symbols for architecture x86_64: "_LLVMInitializeHexagonAsmPrinter", referenced from: LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o "_LLVMInitializeHexagonTargetMC", referenced from: LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o LTOModule::makeLTOModule(llvm::MemoryBuffer*, std::string&) in LTOModule.o "_LLVMInitializeHexagonTarget",...

...; my fresh checkout should have failed as well. Any suggestions as to what I could >> have done wrong? > FWIW, I am getting the same linker errors on OS X: > > Undefined symbols for architecture x86_64: > "_LLVMInitializeHexagonAsmPrinter", referenced from: > LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o > "_LLVMInitializeHexagonTargetMC", referenced from: > LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o > LTOModule::makeLTOModule(llvm::MemoryBuffer*, std::string&) in > LTOModule.o > "_LLVMIniti...

Hi folks, I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes. The x86_64 build on the buildbot is failing, however. Here's the build error: llvm[2]: Linking Debug+Asserts executable llvm-mc /home/baldrick/osuosl/slave/llvm-x86_64/llvm/tools/llvm-mc/Debug+Asserts/llvm-mc.o: In function

...ny suggestions as to what I could >>>> have done wrong? >>> FWIW, I am getting the same linker errors on OS X: >>> >>> Undefined symbols for architecture x86_64: >>> "_LLVMInitializeHexagonAsmPrinter", referenced from: >>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>> "_LLVMInitializeHexagonTargetMC", referenced from: >>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>> LTOModule::makeLTOModule(llvm::MemoryBuffer*, std::string&) in LTOModule.o >&...

...gt;>> have done wrong? >>>>> FWIW, I am getting the same linker errors on OS X: >>>>> >>>>> Undefined symbols for architecture x86_64: >>>>> "_LLVMInitializeHexagonAsmPrinter", referenced from: >>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>> "_LLVMInitializeHexagonTargetMC", referenced from: >>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>> LTOModule::makeLTOModule(llvm::MemoryBuffer*, std::string&am...

...have failed as well. Any suggestions as to what I could >>> have done wrong? >> FWIW, I am getting the same linker errors on OS X: >> >> Undefined symbols for architecture x86_64: >> "_LLVMInitializeHexagonAsmPrinter", referenced from: >> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >> "_LLVMInitializeHexagonTargetMC", referenced from: >> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >> LTOModule::makeLTOModule(llvm::MemoryBuffer*, std::string&) in LTOModule.o >> "...

...hat I could >>>>> have done wrong? >>>> FWIW, I am getting the same linker errors on OS X: >>>> >>>> Undefined symbols for architecture x86_64: >>>> "_LLVMInitializeHexagonAsmPrinter", referenced from: >>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>> "_LLVMInitializeHexagonTargetMC", referenced from: >>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>> LTOModule::makeLTOModule(llvm::MemoryBuffer*, std::string&) >&gt...

...e wrong? >>>>>> FWIW, I am getting the same linker errors on OS X: >>>>>> >>>>>> Undefined symbols for architecture x86_64: >>>>>> "_LLVMInitializeHexagonAsmPrinter", referenced from: >>>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>>> "_LLVMInitializeHexagonTargetMC", referenced from: >>>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>>> LTOModule::makeLTOModule(llvm::MemoryBuffer*, st...

LTOCodeGenerator::addModule (which is wrapped by lto_codegen_add_module) takes an LTOModule as an argument and links the latter's llvm::Module into its own. It does not change the latter's llvm::Module. The lto_module_dispose API call destroys an LTOModule. This frees the LTOModule's llvm::Module, but...

...ively maintained, because the focus of whole-program optimization is now on the gold plugin. Is that the case, or am I missing something? Running searches over the source tree, it seems the Linker class that actually implements the functionality of llvm-link is not used by any other modules except LTOCodeGenerator. I couldn't find anything referencing LTOCodeGenerator. Does the gold plugin or anything else use LTOCodeGenerator? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150210/eef50240/attachment.html>

...ile 'main.bc': Linking COMDATs named '??_7_Iostream_error_category at std@@6B@': invalid selection kinds! Would it be the case that llvm-lto is also deprecated in favor of the gold plugin? On Tue, Feb 10, 2015 at 4:47 PM, Teresa Johnson <tejohnson at google.com> wrote: > LTOCodeGenerator is used by the llvm-lto tool, which is a standalone > tool for doing LTO links. > > Teresa > > On Tue, Feb 10, 2015 at 8:37 AM, Russell Wallace > <russell.wallace at gmail.com> wrote: > > Following on from my last question, based on such information as I've > be...

> On Aug 9, 2016, at 9:24 AM, Kevin Choi via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -Wl,--plugin=LLVMgold.so,--plugin-opt=emit-llvm This is totally Gold specific. The fact that he mentions using LTOCodeGenerator makes me think that he does not use Gold. > > http://llvm.org/docs/CommandGuide/opt.html <http://llvm.org/docs/CommandGuide/opt.html> > http://llvm.org/docs/CommandGuide/llc.html <http://llvm.org/docs/CommandGuide/llc.html> > > "The llc command compiles LLVM sourc...

In LTOCodeGenerator.cpp there are some options related to optimization remarks. On MacOS, I can pass in this option to enable them: -Wl,-mllvm,-lto-pass-remarks-output=remarks But on Linux using 2.29.1 binutils version of gold, I try this alternative: -Wl,--plugin-opt,-lto-pass-remarks-output=remarks But I...

...;>>>> FWIW, I am getting the same linker errors on OS X: >>>>>>> >>>>>>> Undefined symbols for architecture x86_64: >>>>>>> "_LLVMInitializeHexagonAsmPrinter", referenced from: >>>>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>>>> "_LLVMInitializeHexagonTargetMC", referenced from: >>>>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>>>> LTOModule::makeLTOModule(llvm::Memor...

...semantic ,for something like you emit .S file (FileType=CGFT_AssemblyFile), Then we pass this .S file to our native assembler and the linker .....any switch/ options do so ? i.e something like as we have "-no-integrated-as" for clang driver . Currently ,we thought of hacking the LTOCodeGenerator.cpp for the same . The bottom-line is that ,we need to use our native assembler ,not the builtin . Any thoughts on this ? We are trying on 3.6 and 3.8 versions. Thank you ~Umesh

...Nodes" function It goes through OwnedModules and check if a MDNode is used by any of the modules, if not remove it. One implementation is to mark a visited MDNode used when traversing the module. After done traversing all modules, we can delete MDNodes in MDNodeSet that are not marked. In LTOCodeGenerator, add a vector of source modules that are added (these source modules will be linked with DestroySource mode). In LTOCodeGenerator:: compile_to_file, delete all source modules that are linked in, then call LLVMContext::removeUnusedMDNodes —> I can’t find a better place to call the function. When...

...piler flags LDFLAGS - linker flags So, you would do the following in sh/ksh syntax: CC=llvm-gcc CXX=llvm-g++ CFLAGS="-emit-llvm" export CC export CXX export CFLAGS ./configure > > 1) Create your own libLTO and add your pass to it. Do a code diff > between /safecode/tools/LTO/LTOCodeGenerator.cpp > and /llvm/tools/lto/LTOCodeGenerator.cpp to figure out what changes > are needed to do this. > 2) Make a backup copy of the original linker /usr/lib/libLTO.dylib. > 3) Copy your libLTO.dylib to /usr/lib. > 4) Open Makefiles in your target project and change CC and CFLAGS as...

...teps I've taken. John -- a small question: I thought I wouldn't need to touch Makefiles at all, but that wasn't the case. Could you take a look at Step 4) and tell me what you think? Thanks! 1) Create your own libLTO and add your pass to it. Do a code diff between /safecode/tools/LTO/LTOCodeGenerator.cpp and /llvm/tools/lto/LTOCodeGenerator.cpp to figure out what changes are needed to do this. 2) Make a backup copy of the original linker /usr/lib/libLTO.dylib. 3) Copy your libLTO.dylib to /usr/lib. 4) Open Makefiles in your target project and change CC and CFLAGS as follows: CC=llvm-gcc CFLAGS...

...s through OwnedModules and check if a MDNode is used by any of the > modules, if not remove it. > One implementation is to mark a visited MDNode used when traversing the > module. After done traversing all modules, we can delete MDNodes in > MDNodeSet that are not marked. > > In LTOCodeGenerator, add a vector of source modules that are added (these > source modules will be linked with DestroySource mode). > In LTOCodeGenerator:: compile_to_file, delete all source modules that are > linked in, then call LLVMContext::removeUnusedMDNodes > —> I can’t find a better place to call...

...nd check if a MDNode is used by any of >> the modules, if not remove it. >> One implementation is to mark a visited MDNode used when traversing the >> module. After done traversing all modules, we can delete MDNodes in >> MDNodeSet that are not marked. >> >> In LTOCodeGenerator, add a vector of source modules that are added (these >> source modules will be linked with DestroySource mode). >> In LTOCodeGenerator:: compile_to_file, delete all source modules that are >> linked in, then call LLVMContext::removeUnusedMDNodes >> —> I can’t find a bett...