search for: createtargetmachin

...cator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>, llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool) (in /home/preejackie/kld/toy) ==4153==    by 0x46CE5B: createTargetMachine (TargetRegistry.h:397) ==4153==    by 0x46CE5B: main (kjit.cpp:1337) ==4153==  Address 0x4 is not stack'd, malloc'd or (recently) free'd | Source compile command : clang++ -g -O3 kjit.cpp `llvm-config --cxxflags --ldflags --system-libs --libs all` -o toy Please, let me know that if...

...04afee0 in llvm::optional_detail::OptionalStorage<llvm::Reloc::Model, true>::OptionalStorage(llvm::optional_detail::OptionalStorage<llvm::Reloc::Model, true> const&) ()| |Source code: | TargetOptions opt; autoRM =Optional<Reloc::Model>(); autoTheTargetMachine = Target->createTargetMachine(TargetTriple, CPU, Features, opt, RM); Whether this behavior is already notified and is there any workaround available for it ? I would be great to know the root cause for this behavior. Of course, the kaleidoscope is friendly and good introduction to llvm for beginners, thank you very much f...

When I pass an empty string for cpu and features to createTargetMachine, and then use LLVMGetTargetMachineCPU() and LLVMGetTargetMachineFeatureString() to get the strings back, they are still empty. Is there a way to have llvm compute the effective cpu/features string, and provide it so that I can inspect it? I'm trying to figure out how the cpu/features string t...

...>>>>> punt to using the command line options that currently exist and the >>>>> existing ParseCommandLineOptions call from clang. >>>>> >>>>> >>>> When option -target-abi=apcs-gnu for ARM is used for clang, EmitAssemblyHelper::CreateTargetMachine >>>> passes FeatruresStr="+apcs" to Target::createTargetMachine. Do we have >>>> anything else we have to pass to the backend in this case? >>>> >>> >>> Not yet, but the option can be a backend option rather than a subtarget >>&...

...tion - right now, if we wanted, we could punt to >>> using the command line options that currently exist and the existing >>> ParseCommandLineOptions call from clang. >>> >>> >> When option -target-abi=apcs-gnu for ARM is used for clang, EmitAssemblyHelper::CreateTargetMachine >> passes FeatruresStr="+apcs" to Target::createTargetMachine. Do we have >> anything else we have to pass to the backend in this case? >> > > Not yet, but the option can be a backend option rather than a subtarget > feature - and I'm probably going to do t...

...he bitcode with `-flto=thin -c` and sure it has a GLOBALVAL_SUMMARY_BLOCK. And there’s no RegularLTO partition only ThinLTO bicode. > Where is it aborting in the backend? It aborts at ` report_fatal_error("Failed to setup codegen")` in of codegen() of LTOBackend.cpp. And before that in createTargetMachine() it also warns ‘xxx is not a recognized processor’. But the program should return before run into backend() IIUC since all I want is using lld with `-thinlto-index-only` option to generate *.thinlto.bc and feed it and bitocde to clang to invoke target-specific optimizations(we use gnu as and ld)....

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

...cted that using the dragonegg plugin to generate native code > directly would internally do more or less the same as the explicit step of > approach 2, but this does not seem to be the case. Any ideas why this > happens? different arguments are being passed to the code generators. In the CreateTargetMachine function in Backend.cpp options like -fPIC, -fomit-frame-pointer and so on are transformed into LLVM languages and passed to the code generators. Same goes for feature strings (whether you are targeting a machine supporting SSE and so on). A few more generic codegen options are set in ConfigureL...

...AllTargetInfos() 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; ==== END CODE SNIPPET ==== For your case, you should be able to find TripleStr and FeatureStr in somewhere. And also there&...

Hello guys, I'm using llvm 3.3 on windows with mingw (triple: "i386-unknown-mingw32") to compile IR code that my program generates. I do it in two phases: first I emit assembly code and then assemble it. TargetMachine targetMachine = target.createTargetMachine(triple); targetMachine.setAsmVerbosityDefault(true); targetMachine.setFunctionSections(true); targetMachine.setDataSections(true); targetMachine.getOptions().setNoFramePointerElim(true); output.reset(); targetMachine.emit(module, output, CodeGenFile...

> > As I understand it your proposal aims to help solve the issue of getting the complete > > set of ABI information to every part of LLVM that needs it and you are saying > > TargetMachine should encapsulate that data directly. > Essentially. To be more precise I'm saying that TargetMachine (or an MC level equivalent > - see TargetSubtargetInfo/MCSubtargetInfo) should

Hi all, I tried using dragonegg to compile some numerical software of ours. I tried out two different approaches expecting both would yield the same results: 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f (I ommitted a bunch of additional arguments for brevity) 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir -S -o test.ll test.f llc -O0 -o test.s test.ll as

...odeGenOpt::Less; break; case '2': OLvl = CodeGenOpt::Default; break; case '3': OLvl = CodeGenOpt::Aggressive; break; } TargetOptions targetopts = InitTargetOptionsFromCodeGenFlags(); std::unique_ptr<TargetMachine> tmachine(moduletarget->createTargetMachine(moduletriple.getTriple(), cpuname, ftrlist, targetopts, Reloc::Default, CodeModel::Default, OLvl)); assert(tmachine && "Could not allocate target machine!"); assert(module && "Should have exited if we didn't have a module!"); if (FloatA...

...ragonegg plugin to generate native code >> directly would internally do more or less the same as the explicit step of >> approach 2, but this does not seem to be the case. Any ideas why this >> happens? > different arguments are being passed to the code generators. In the > CreateTargetMachine function in Backend.cpp options like -fPIC, > -fomit-frame-pointer and so on are transformed into LLVM languages > and passed to the code generators. Same goes for feature strings > (whether you are targeting a machine supporting SSE and so on). A > few more generic codegen options a...

...tion into the > backend for such an option - right now, if we wanted, we could punt to > using the command line options that currently exist and the existing > ParseCommandLineOptions call from clang. > > When option -target-abi=apcs-gnu for ARM is used for clang, EmitAssemblyHelper::CreateTargetMachine passes FeatruresStr="+apcs" to Target::createTargetMachine. Do we have anything else we have to pass to the backend in this case? > That said, it's a pretty awful hack to use them. For some of my particular > needs I've got some code around unifying the DataLayout creatio...

.... Does anyone have any suggestions as to how I might get to disassemble the post-linked code? Thanks once again! -matt On Wed, Sep 17, 2014 at 2:35 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > You need to call llvm::sys::getHostCPUName() and pass the result to > createTargetMachine() passed to the JIT. This patch should be applied: > > http://llvm.org/bugs/show_bug.cgi?id=17422 > > Anyhow, the JIT was removed from current code and will not be in next LLVM > release. > > Yaron > > > 2014-09-17 22:27 GMT+03:00 Matt Godbolt <matt at godbolt.org...

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

...= CodeGenOpt::Default; break; >> case '3': OLvl = CodeGenOpt::Aggressive; break; >> } >> >> TargetOptions targetopts = InitTargetOptionsFromCodeGenFlags(); >> >> std::unique_ptr<TargetMachine> tmachine(moduletarget->createTargetMachine(moduletriple.getTriple(), cpuname, ftrlist, targetopts, Reloc::Default, CodeModel::Default, OLvl)); >> >> assert(tmachine && "Could not allocate target machine!"); >> >> assert(module && "Should have exited if we didn't h...

...case '2': OLvl = CodeGenOpt::Default; break; > case '3': OLvl = CodeGenOpt::Aggressive; break; > } > > TargetOptions targetopts = InitTargetOptionsFromCodeGenFlags(); > > std::unique_ptr<TargetMachine> tmachine(moduletarget->createTargetMachine(moduletriple.getTriple(), cpuname, ftrlist, targetopts, Reloc::Default, CodeModel::Default, OLvl)); > > assert(tmachine && "Could not allocate target machine!"); > > assert(module && "Should have exited if we didn't have a module!&qu...

...enerate native code >>> directly would internally do more or less the same as the explicit step of >>> approach 2, but this does not seem to be the case. Any ideas why this >>> happens? >> different arguments are being passed to the code generators. In the >> CreateTargetMachine function in Backend.cpp options like -fPIC, >> -fomit-frame-pointer and so on are transformed into LLVM languages >> and passed to the code generators. Same goes for feature strings >> (whether you are targeting a machine supporting SSE and so on). A >> few more generic c...