search for: initializealltargets

Do the InitializeAllTargets*() routines call the initialisation routines of all targets even when only some are built ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170323/08bd52a0/attachment.html>

As the question asks, I'm having some trouble using initializeAllTargets(). I have a CMakeLists that uses: llvm_map_components_to_libnames(LLVM_LIBS ... AllTargetsAsmParsers AllTargetsAsmPrinters AllTargetsDescs AllTargetsInfos ...) However, even with these, when I try to compile my program, I get linker errors: CMakeFiles/sxhc.dir/src/main.cpp....

...deGenerator.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 LTOCodeGenerator.o ld: symbol(s) not found for architecture x86_64 Are you building with CMake or configure? /jakob -------------- next part -------------- An HTML attac...

...MInitializeHexagonTargetMC", 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 LTOCodeGenerator.o > ld: symbol(s) not found for architecture x86_64 > > Are you building with CMake or configure? > > /jakob > I should have a...

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

...", 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 LTOCodeGenerator.o >>> ld: symbol(s) not found for architecture x86_64 >>> >>> Are you building with CMake or configur...

...;>>> 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 LTOCodeGenerator.o >>>>> ld: symbol(s) not found for architecture x86_64 >>>>> >>>>>...

...eHexagonTargetMC", 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 LTOCodeGenerator.o >> ld: symbol(s) not found for architecture x86_64 >> >> Are you building with CMake or configure? >> >&gt...

...gt;> 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 LTOCodeGenerator.o >>>> ld: symbol(s) not found for architecture x86_64 >>>> >>>> Are you building wit...

...; 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 LTOCodeGenerator.o >>>>>> ld: symbol(s) not found for architecture x86_64 >>>>>> >...

...be a string buffer that contains the PTX, which you can load into the CUDA runtime. As for determining if PTX support is compiled into the LLVM binary you are using, you could register all targets and then check if you can create a Target for the "nvptx" or "nvptx64" triple: InitializeAllTargets(); InitializeAllTargetMCs(); InitializeAllAsmPrinters(); InitializeAllAsmParsers(); std::string Err; const Target *Tgt = TargetRegistry::lookupTarget("nvptx64", Err); if (Tgt) { // nvptx target is available } else { // nvptx target is not available } More inform...

...ere does not seem to be a fundamental need for them to be inlined. This is why I propose to make them non-inline, normal functions that get declared in their current header and defined in lib/IR/Core.cpp. The list of functions affected by this is: void llvm::InitializeAllTargetInfos () void llvm::InitializeAllTargets () void llvm::InitializeAllTargetMCs () void llvm::InitializeAllAsmPrinters () void llvm::InitializeAllAsmParsers () void llvm::InitializeAllDisassemblers () bool llvm::InitializeNativeTarget () bool llvm::InitializeNativeTargetAsmPrinter () bool llvm::InitializeNativeTargetAsmParser () bool llvm::...

...odeGenerator::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 LTOCodeGenerator.o >>>>>>> ld: symbol(s) not found for architecture x86_64 >>>>&g...

OK, fine -- an example of MCJIT that sets up for PTX JIT would also be helpful. On Dec 6, 2013, at 12:32 PM, Eli Bendersky <eliben at google.com> wrote: > > You'll have to switch to MCJIT for this purpose. Legacy JIT doesn't emit PTX. > > Eli -- Larry Gritz lg at larrygritz.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

...ring TripleStr = "i686-unknown-linux"; // hard coded for example const std::string FeatureStr = ""; // hard coded for example std::string Err; const Target* T; TargetMachine* TM = NULL; const TargetData* TD; // Or just call InitializeAllTargetInfos() and InitializeAllTargets() for all targets enabled by your LLVM build. LLVMInitializeX86TargetInfo(); LLVMInitializeX86Target(); T = TargetRegistry::lookupTarget(TripleStr, Err); if(!Err.empty()) // error handling // Create TargetMachine TM = T->createTargetMachine(TripleStr, FeatureStr...

...quot;Writer" to allow a custom MCJITObjectWriter to be used. Can you give us some feedbacks on the general idea and on this 2 particular hooks ? Currently MCJIT has one unittest and the binary size is quite big (~110MB in debug...) because before using the MC framework we need to call "InitializeAllTargets()" and friends (same as llc does). For the JIT, we need only the "host" backend and "InitializeHostTarget()"-like method doesn't seem to exist. Do you have an opinion on this ? Attached you will find the patch introducing the first MCJIT draft. Can you comment on this...

...hat contains the PTX, which you can load into the CUDA runtime. > > As for determining if PTX support is compiled into the LLVM binary you are using, you could register all targets and then check if you can create a Target for the "nvptx" or "nvptx64" triple: > > InitializeAllTargets(); > InitializeAllTargetMCs(); > InitializeAllAsmPrinters(); > InitializeAllAsmParsers(); > > std::string Err; > const Target *Tgt = TargetRegistry::lookupTarget("nvptx64", Err); > if (Tgt) { > // nvptx target is available > } else { >...

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part

...late <typename T> inline std::vector<T> singletonSet (T t) { std::vector<T> Vec; Vec.push_back(std::move(t)); return Vec; } /// /// THIS is the function I want my IR to call /// extern "C" { float sqr (float x) { return x*x; } } void simple () { llvm::InitializeAllTargets(); llvm::InitializeAllTargetMCs(); llvm::InitializeAllAsmPrinters(); llvm::InitializeAllAsmParsers(); llvm::LLVMContext Context; std::unique_ptr<llvm::TargetMachine> TM (llvm::EngineBuilder().selectTarget()); std::unique_ptr<llvm::DataLayout> DL; DL.reset (ne...

...CJITObjectWriter to be used. > > Can you give us some feedbacks on the general idea and on this 2 > particular hooks ? > > > Currently MCJIT has one unittest and the binary size is quite big > (~110MB in debug...) because before using the MC framework we need to > call "InitializeAllTargets()" and friends (same as llc does). For the > JIT, we need only the "host" backend and "InitializeHostTarget()"-like > method doesn't seem to exist. Do you have an opinion on this ? > > Attached you will find the patch introducing the first MCJIT draft. >...