search for: lookuptarget

...ions/48360685/no-targets-in-targetregistry I have the following code, which should get the default llvm::Target. auto const targetTriple = llvm::sys::getDefaultTargetTriple(); llvm_module.setTargetTriple(targetTriple); std::string error; auto const * target = llvm::TargetRegistry::lookupTarget(targetTriple, error); if (target == nullptr) { auto targets = llvm::TargetRegistry::targets(); size_t targetCount = 0; for (auto const & _ : targets) { ++targetCount; } ERROR(Unknown, "llvm::TargetRegistry::lookupTarget failed for &qu...

Hi! is there a way to get the c backend using llvm::TargetRegistry::lookupTarget()? e.g. llvm::TargetRegistry::lookupTarget("c", error)? - Jochen

...mp;,llvm::LLVMContext&) > > > Without mapping to line numbers this is not very helpful: moduleToObjectFile never calls schedulePass. > > Also you didn't answer my previous question about the crash. > > >> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target > > Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? > That's unexpected and I'd be worried about my program. > > -- > Mehdi > &gt...

The stack trace: llvm::PMTopLevelManager::addImmutablePass(llvm::ImmutablePass*) llvm::PMTopLevelManager::schedulePass(llvm::Pass*) moduleToObjectFile(llvm::Module*,std::string&,llvm::LLVMContext&) Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target > On Mar 24, 2016, at 1:14 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Assuming you are talking about this line: > > passmanager.add(tliwp); > > I don't see anything obviously wrong....

...oObjectFile(llvm::Module*,std::string&,llvm::LLVMContext&) Without mapping to line numbers this is not very helpful: moduleToObjectFile never calls schedulePass. Also you didn't answer my previous question about the crash. > Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? That's unexpected and I'd be worried about my program. -- Mehdi > > On Mar 24, 2016, at 1:14...

...> Without mapping to line numbers this is not very helpful: moduleToObjectFile never calls schedulePass. >>> >>> Also you didn't answer my previous question about the crash. >>> >>> >>>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >>> >>> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >>> That's unexpected and I'd be worried about my program. >>&gt...

...> >> >> Without mapping to line numbers this is not very helpful: moduleToObjectFile never calls schedulePass. >> >> Also you didn't answer my previous question about the crash. >> >> >>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >> >> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >> That's unexpected and I'd be worried about my program. >> >> --...

...s is not very helpful: moduleToObjectFile never calls schedulePass. >>>>> >>>>> Also you didn't answer my previous question about the crash. >>>>> >>>>> >>>>>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >>>>> >>>>> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >>>>> That's unexpected and I'd be worried about...

...to line numbers this is not very helpful: moduleToObjectFile never calls schedulePass. >>>> >>>> Also you didn't answer my previous question about the crash. >>>> >>>> >>>>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >>>> >>>> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >>>> That's unexpected and I'd be worried about my program....

...l: moduleToObjectFile never calls schedulePass. >>>>>> >>>>>> Also you didn't answer my previous question about the crash. >>>>>> >>>>>> >>>>>>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >>>>>> >>>>>> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >>>>>> That's unexpected and I'd be w...

...e never calls schedulePass. >>>>>>> >>>>>>> Also you didn't answer my previous question about the crash. >>>>>>> >>>>>>> >>>>>>>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >>>>>>> >>>>>>> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >>>>>>> That's unexpected and...

...lePass. >>>>>>>> >>>>>>>> Also you didn't answer my previous question about the crash. >>>>>>>> >>>>>>>> >>>>>>>>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >>>>>>>> >>>>>>>> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >>>>>>>> That's une...

...>>>>>> >>>>>>>>> Also you didn't answer my previous question about the crash. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target >>>>>>>>> >>>>>>>>> Do you mean that running it multiple time does not always produce the same behavior in the call to lookupTarget? >>>>>>>>> Th...

...MCRegisterInfo, seems to be a bit beyond me. Specifically, while I can get a target architecture from a given ObjectFile using getArch(), I’m not sure how to turn this into an MCRegisterInfo (or really anything, such as Target, that could lead to one). My most recent attempt, using TargetRegistry::lookupTarget() to get a Target and then use createMCRegInfo(), fails with a complaint that no targets are registered, and I’m still too new to LLVM’s depths to know what I’m missing. I’m not even entirely convinced this is the right approach. I haven’t found anything from Googling either; almost everything out...

...xt &Context) { SMDiagnostic error; Triple moduletriple = Triple(module->getTargetTriple()); if (moduletriple.getTriple().empty()) moduletriple.setTriple(sys::getDefaultTargetTriple()); std::string lookuperror; const Target *moduletarget = TargetRegistry::lookupTarget(MArch, moduletriple, lookuperror); if (!moduletarget) { errs() << lookuperror; return 1; } std::string cpuname = getCPUStr(), ftrlist = getFeaturesStr(); CodeGenOpt::Level OLvl = CodeGenOpt::Default; switch ('2') {...

...error; > Triple moduletriple = Triple(module->getTargetTriple()); > > if (moduletriple.getTriple().empty()) > moduletriple.setTriple(sys::getDefaultTargetTriple()); > > std::string lookuperror; > const Target *moduletarget = TargetRegistry::lookupTarget(MArch, moduletriple, lookuperror); > > if (!moduletarget) { > errs() << lookuperror; > return 1; > } > > std::string cpuname = getCPUStr(), > ftrlist = getFeaturesStr(); > > CodeGenOpt::Level OLvl = C...

Hi everyone, I was happily using MCJIT for over a year until yesterday when I created a function call with an argument of a struct type. That caused a crash in SelectionDAG around DataLayout::getAlignment(). I remember the noise about the DataLayout started being mandatory. But I cannot find precise information. Should I set the DataLayout in every Module created? Where can I get the

...u 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 information about the PTX target can be found at: http://llvm.org/docs/NVPTXUsage.html On Fri, Dec 6, 2013 at 3:43 PM, Larry Gritz <lg at larrygritz.com> wrot...

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:

...: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); if(TM == NULL) // error handling // TD is what you want. TD = TM->getTargetData(); [...] // Free TM delete TM...