search for: ltomodul

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 also invalidates strings returned by, e.g., lto_module_get_symbol_name....

Hello everyone, ...I should have used a different subject line in the first place... I've asked Rafael a question about GlobalAlias handling in LTOModule::parseSymbols, but he seems to be on vacation... Does anyone knows the answer? Thanks a lot! Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmde...

While looking at adding a TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? - Stephen Crane -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piperm...

While looking at adding a new TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? - Stephen Crane -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piper...

...ed 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", referenced from: llvm::InitializeAllTargets() in LTOCodeGenerator.o "_LLVMInitializeHexagonTargetInfo", referenced from: llvm::InitializeAllTargets() in LTOCodeG...

...re 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", referenced from: > llvm::InitializeAllTargets() in LTOCodeGenerator.o > "_LLVMInitializeHexagonTargetInfo", referenced from: > llvm::Initiali...

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

...tializeHexagonAsmPrinter", 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", referenced from: >>> llvm::InitializeAllTargets() in LTOCodeGenerator.o >>> "_LLVMInitializeHexagonTargetInfo", referenced from: >&gt...

On 19 September 2014 15:54, Steven Wu <stevenwu at apple.com> wrote: > Yes, we don’t need to edit the assembly in the file, but we need to modified the CHECK line to reflect the output of current llvm-dis. I was talking about updating the CHECK in all the previous version. Does that make sense? Yes, the CHECK lines would have to be updated, but that seems like a pretty small annoyance.

...is isn't > straight forward as we cannot distinguish them just by looking at the > file header alone, we would need to parse the sections and look for a > .llvmbc section. We then need to add special handling of these native > object wrappers. Ok, I see. Does it help that there are LTOModule (lto_module_* in the C API) interfaces for checking if a file contains bitcode (regardless of whether it is straight-up or native-wrapped)? I don't know how hard in your linker it is to query these when deciding whether to treat the object file as bitcode or not, or how hard it is to pass the...

...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", referenced from: >>>>> llvm::InitializeAllTargets() in LTOCodeGenerator.o >>>>> "_LLVMInitializeHexagonTargetInfo",...

..."_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", referenced from: >> llvm::InitializeAllTargets() in LTOCodeGenerator.o >> "_LLVMInitializeHexagonTargetInfo", referenced from: >> llvm...

...mPrinter", 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", referenced from: >>>> llvm::InitializeAllTargets() in LTOCodeGenerator.o >>>> "_LLVMInitializeHexagonTargetInfo&q...

...of bitcode files via gold plugin based on LLVM 3.4. When I find a thumbv7 bitcode with a couple of module asms, I get a segfault in ARMAsmParser::parseDirectiveFnStart because getTargetStreamer returns NULL. Frankly, I don't see how this is supposed to work because as far as I understood LTOModule::addAsmGlobalSymbols only creates a RecordStreamer which is then attached to the MCTargetAsmParser, and no TargetStreamer is ever created. The places that explicitly call createAsmStreamer are only writing assembly as llvm-mc or cc1as. I've tried to follow that scheme in addAsmGlobalSymb...

...>>>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>>> "_LLVMInitializeHexagonTargetMC", referenced from: >>>>>> LTOCodeGenerator::LTOCodeGenerator() in LTOCodeGenerator.o >>>>>> LTOModule::makeLTOModule(llvm::MemoryBuffer*, std::string&) in LTOModule.o >>>>>> "_LLVMInitializeHexagonTarget", referenced from: >>>>>> llvm::InitializeAllTargets() in LTOCodeGenerator.o >>>>>> "_LLVMInitializeHexagonTarget...

...------------------------ The first planned sets of patches are enablers for ThinLTO work: a. LTO directory structure Restructure the LTO directory to remove circular dependence when ThinLTO pass added. Because ThinLTO is being implemented as a SCC pass within Transforms/IPO, and leverages the LTOModule class for linking in functions from modules, IPO then requires the LTO library. This creates a circular dependence between LTO and IPO. To break that, we need to split the lib/LTO directory/library into lib/LTO/CodeGen and lib/LTO/Module, containing LTOCodeGenerator and LTOModule, respectively. On...

...blers for ThinLTO work: >> >> >> a. LTO directory structure >> >> >> Restructure the LTO directory to remove circular dependence when >> ThinLTO pass added. Because ThinLTO is being implemented as a SCC pass >> within Transforms/IPO, and leverages the LTOModule class for linking >> in functions from modules, IPO then requires the LTO library. This >> creates a circular dependence between LTO and IPO. To break that, we >> need to split the lib/LTO directory/library into lib/LTO/CodeGen and >> lib/LTO/Module, containing LTOCodeGener...

...e. Then the bitcode gets passed to the linker. The linker looks through the bitcode (via the gold plugin) searching for symbols it needs to resolve. But any memcpy() calls in myTest.c got converted to llvm.memcpy() calls in the bitcode. Any symbols that start with 'llvm.' get ignored in LTOModule.cpp. So the linker doesn't know that it needs memcpy. Now once the linker processes opt.a it doesn't know that it needs memcpy, so the linker doesn't keep the definition of memcpy from opt.a. After the (full) compilation of myTest is complete, the linker winds up trying to pull me...

...nned sets of patches are enablers for ThinLTO work: > > > a. LTO directory structure > > > Restructure the LTO directory to remove circular dependence when > ThinLTO pass added. Because ThinLTO is being implemented as a SCC pass > within Transforms/IPO, and leverages the LTOModule class for linking > in functions from modules, IPO then requires the LTO library. This > creates a circular dependence between LTO and IPO. To break that, we > need to split the lib/LTO directory/library into lib/LTO/CodeGen and > lib/LTO/Module, containing LTOCodeGenerator and LTOModu...

...ctory structure >>>>> >>>>> >>>>> Restructure the LTO directory to remove circular dependence when >>>>> ThinLTO pass added. Because ThinLTO is being implemented as a SCC pass >>>>> within Transforms/IPO, and leverages the LTOModule class for linking >>>>> in functions from modules, IPO then requires the LTO library. This >>>>> creates a circular dependence between LTO and IPO. To break that, we >>>>> need to split the lib/LTO directory/library into lib/LTO/CodeGen and >>>...