search for: targetregistry

This is from https://stackoverflow.com/questions/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...

...e don't make any sort of guarantee about that, and such a > guarantee is not necessary for correctness. Aren't values in Core.h supposed to be used by users of API and they should match enums, or what they are for then? What are they matched against? >> > Also, llvm/Support/TargetRegistry.h and llvm/Target/TargetRegistry.h >> > define two different version of some classes, particularly llvm::Target. >> > Fields with the same names have different offsets. >> > Are they intended to be different, and if yes, why? > llvm/Target/TargetRegistry.h does not...

Looks like constants in include/llvm-c/Core.h aren't in sync with enums. For example, LLVMAdd is 8 in Core.h and llvm::Instruction::LLVMAdd evaluates to 9 in C++. Same for Cast Operators section and possibly in other places. Also, llvm/Support/TargetRegistry.h and llvm/Target/TargetRegistry.h define two different version of some classes, particularly llvm::Target. Fields with the same names have different offsets. Are they intended to be different, and if yes, why? All based on rev.139973. Also I got dropped from the mailing list on 9/15 -- no mess...

...or example, LLVMAdd is 8 in Core.h and  llvm::Instruction::LLVMAdd > evaluates to 9 in C++. > Same for Cast Operators section and possibly in other places. Yes; we don't make any sort of guarantee about that, and such a guarantee is not necessary for correctness. > Also, llvm/Support/TargetRegistry.h and llvm/Target/TargetRegistry.h > define two different version of some classes, particularly llvm::Target. > Fields with the same names have different offsets. > Are they intended to be different, and if yes, why? llvm/Target/TargetRegistry.h does not exist on trunk. > All based on...

Hi, The code @ line 584 of TargetRegistry.h effectively suppresses specifying any AsmStreamer constructor function but stock createAsmStreamer one. Is it by intention or condition should be replaced with != ? Best regards, Max

On Thu, Sep 8, 2011 at 12:12 AM, Max Kazakov <max.kazakov at gmail.com> wrote: > Hi, > > The code @ line 584 of TargetRegistry.h effectively suppresses specifying any > AsmStreamer constructor function but stock createAsmStreamer one. Is it by > intention or condition should be replaced with != ? Hi Max, are you sure that you have the tip-of-tree version of include/llvm/Support/TargetRegistry.h? static void Regi...

Hi and merry X-Mas! At initialization I add some targets (e.g. LLVMInitializeX86TargetInfo()). Is this guaranteed not to allocate memory to prevent memory leaks? If you use llvm in a plug-in then it is possible to load and unload the plugin. As there is no way to clear the target registry and I do not see a "new" at the first glance I assume it does not allocate heap memory. Is this

Hi Ivan, Sorry for the confusion - in the latest version it is line 760: static void RegisterAsmStreamer(Target &T, Target::AsmStreamerCtorTy Fn) { if (T.AsmStreamerCtorFn == createAsmStreamer) T.AsmStreamerCtorFn = Fn; } Best regards, Max

...eference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst)); ^~ /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:514:66: note: passing argument to parameter 'CE' here std::unique_ptr<MCCodeEmitter> &&CE, ^ /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fu...

...er(); delete Assembler; } In the depths of a fever from a head-cold, I snapped. I've been hacking MC to convert these raw pointers (and worse: references!) to unique_ptrs (apologies to people whose backbends I've broken), but I hit a big blocker when I get to Target in "llvm/Support/TargetRegistry.h". Target vends MC objects by calling registered ctor functions. E.g.: MCAsmBackend *createMCAsmBackend(const MCRegisterInfo &MRI, StringRef TheTriple, StringRef CPU, const MCTargetOptions &Options) const { if (!MCA...

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

...std::unique_ptr<MCCodeEmitter>' could not > bind to an > lvalue of type 'llvm::MCCodeEmitter *' > UseDwarfDirectory, IP, CE, MAB, ShowInst)); > ^~ > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:514:66: > note: passing argument to parameter 'CE' here > std::unique_ptr<MCCodeEmitter> &&CE, > ^ > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/l...

...CCodeEmitter>' could not >> bind to an >> lvalue of type 'llvm::MCCodeEmitter *' >> UseDwarfDirectory, IP, CE, MAB, ShowInst)); >> ^~ >> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:514:66: >> note: passing argument to parameter 'CE' here >> std::unique_ptr<MCCodeEmitter> &&CE, >> ^ >> /Users/davide/work/llvm-monorepo/llvm-project-20170...

...s actually X86_64-win64, via visual c++ compilation. I also had to fiddle around to get LLVM 2.9 to compile under the custom build system I'm working with). The JIT::selectTarget call infers a triple of "x86_64-pc-win32", which then fails to find a target machine. Interestingly, the TargetRegistry appears to be empty, which doesn't seem right (maybe i haven't linked in a library that populates this?). I also tried specifying MCPU as "X86_64"/"X86" and MArch as "win64"/"w64"/"win32" using EngineBuilder functions, which didn't help...

...g about. Encoding it in metadata > would be inconvenient. I agree that metadata isn't the right way to go, but this argument doesn't fly at all with me. The whole point of these passes are to do target-specific optimizations. The right way to expose this sort of thing is with the new TargetRegistry interfaces. That said, speculatively adding target hooks isn't the right way to go, the client should come first. -Chris

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 ob...

In these days I’ve integrated llc code into my compiler. I had an undefined behaviour because when cl::AddExtraVersionPrinter(TargetRegistry::printRegisteredTargetsForVersion) is called, the modules I give to the code in input to compile got somehow “corrupted" by this function. It is definitely an undefined behaviour because every debug I do, modules gets different changes, producing different assertions every run: - Target tripl...

"Rotem, Nadav" <nadav.rotem at intel.com> writes: > Can you describe which passes may benefit from this information ? My > intuition is that until there are a number of passes which require > this information, there are other ways to provide this > information. One way would be to use Metadata. We have Cray-specific passes that use this information. Some of the

...e*,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. > > -- > M...

...s*) > moduleToObjectFile(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,...