search for: gettargettripl

...Manager *functionPassManager = new llvm::legacy::FunctionPassManager(Mod); llvm::PassRegistry &registry = *llvm::PassRegistry::getPassRegistry(); initializeScalarOpts(registry); functionPassManager->add( new llvm::TargetLibraryInfoWrapperPass(llvm::TargetLibraryInfoImpl(targetMachine->getTargetTriple())) ); still, LV: The Widest register is: 32 bits. so, unfortunately no change. If I dump the Module, it starts with: ; ModuleID = 'module' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" Does this datalayout look good for x86-64 AVX ? Frank On 02/19/20...

...this snippet from LinkModules.cpp: if (!SrcM->getDataLayout().empty() && !DstM->getDataLayout().empty() && SrcM->getDataLayout() != DstM->getDataLayout()) errs() << "WARNING: Linking two modules of different data layouts!\n"; if (!SrcM->getTargetTriple().empty() && DstM->getTargetTriple() != SrcM->getTargetTriple()) { errs() << "WARNING: Linking two modules of different target triples: "; if (!SrcM->getModuleIdentifier().empty()) errs() << SrcM->getModuleIdentifier() << ":...

On Thu, May 31, 2012 at 8:06 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 31, 2012, at 2:39 PM, Justin Holewinski wrote: > > > The attached patch add the ability to programmatically re-direct > outs()/errs() to an arbitrary raw_ostream instance, maintaining the > raw_ostream instances in a stack structure so clients can push/pop streams > at will. The

I have some trouble making the SIMD vector length visible to the passes. My application is basically on the level of 'opt'. What I did in version 3.6 was functionPassManager->add(new llvm::TargetLibraryInfo(llvm::Triple(Mod->getTargetTriple()))); functionPassManager->add(new llvm::DataLayoutPass()); and then the -basicaa and -loop-vectorizer were able to vectorize the input IR for AVX. Now, with 3.8 that didn't compile. What I do instead is just setting the datalayout to the Module (got that from the Kaleido example). Mod...

...dules.cpp: > > if (!SrcM->getDataLayout().empty() && !DstM->getDataLayout().empty() && > SrcM->getDataLayout() != DstM->getDataLayout()) > errs() << "WARNING: Linking two modules of different data layouts!\n"; > if (!SrcM->getTargetTriple().empty() && > DstM->getTargetTriple() != SrcM->getTargetTriple()) { > errs() << "WARNING: Linking two modules of different target triples: "; > if (!SrcM->getModuleIdentifier().empty()) > errs() << SrcM->getModuleIdentifier...

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

...#39;m currently considering > is to use the TargetInfo class from Clang's Basic library which can > be used to obtain target specific parameters (such as sizeof(long)) > given a target triple. Interesting. Maybe I can get enough information from the target triple itself. Module::&getTargetTriple should be enough. I did not think about this, but that might work. Thanks for the pointer. Tobi

On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > sin/cos are libm functions, and so a libcall to those need to honour the > floating point ABI requests. The calling convention to be followed there > should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP, > -mfloat-abi=soft => AAPCS). Exactly, but they're not, and that's

...t do that.  SimplifyLibcalls depends on TargetLibraryInfo, which is an analysis pass. However, TargetLibraryInfo does take a target triple (not a bool though) as constructor argument, defaulting to all-unknown. Maybe instead of being an ImmutablePass it should be a ModulePass so it can use Module::getTargetTriple() in runOnModule()? That should make it more compatible with opt & bugpoint.

...n (TargetTransformInfo and TargetMachine being the most obvious). > During prototyping and exploring, making temporary changes to the > target-independent code is the best way until I understand how to best > implement the final version. For purely personal hacks I'd go via Module::getTargetTriple myself, but then for personal hacks I probably wouldn't even bother checking the target. Cheers. Tim.

..., bool isLittle) : LLVMTargetMachine(T, computeDataLayout(TT, CPU, Options, isLittle), TT, CPU, FS, Options, getEffectiveRelocModel(TT, RM), getEffectiveCodeModel(CM), OL), TargetABI(computeTargetABI(TT, CPU, Options)), TLOF(createTLOF(getTargetTriple())), isLittle(isLittle) { ... } It does not create a separate Subtarget, and its getSubtargetImpl() tries to get the value from SubtargetMap. Is there any downside to keep BPFTargetMachine as is? Or it is worthwhile to implement it in a similar way to X86/ARM? Thanks! Yonghong -------------- ne...

...llvm::raw_fd_ostream osB("B.bc", "", llvm::sys::fs::F_None); llvm::Module *ModuleA = new llvm::Module("A", context); llvm::Module *ModuleB = new llvm::Module("B", context); ModuleA->setDataLayout(M.getDataLayout()); ModuleA-->setTargetTriple(M.getTargetTriple()); ModuleA-->setModuleInlineAsm(M.getModuleInlineAsm()); ModuleB-->setDataLayout(M.getDataLayout()); ModuleB-->setTargetTriple(M.getTargetTriple()); ModuleB-->setModuleInlineAsm(M.getModuleInlineAsm()); for (Function &F : M) { if (F.getName() == "My Criterio...

On Feb 24, 2011, at 12:41 AM, John Criswell wrote: >>>> At the moment I've got this working locally by adding code to the >>>> simplify-libcalls pass. However this will break on targets where >>>> iprintf() isn't available. Is there a sensible place to add information >>>> about which library functions are available for a particular target?

...ion (TargetTransformInfo and TargetMachine being the most obvious). > During prototyping and exploring, making temporary changes to > the target-independent code is the best way until I understand how to best > implement the final version. For purely personal hacks I'd go via Module::getTargetTriple myself, but then for personal hacks I probably wouldn't even bother checking the target. Cheers. Tim.

Hi LLVM-Devs, Sometimes when I am experimenting with a change for my out-of-tree target, I find that to get it working I have to make changes to the target-independent sources for LLVM. Generally I do not like to do this, but sometimes I have not been able to find a pure target-specific solution to the problem I am working on, and have to make these changes in the target-independent code. But

...>> is to use the TargetInfo class from Clang's Basic library which can >> be used to obtain target specific parameters (such as sizeof(long)) >> given a target triple. > > Interesting. Maybe I can get enough information from the target triple > itself. Module::&getTargetTriple should be enough. I did not think about > this, but that might work. Thanks for the pointer. You could also just use a small function to define the API function you wish to use and then use TargetData to get some of the final parts: i.e. if you know you've got something like char GOMP_f...

...and TargetMachine being the most obvious). > >> During prototyping and exploring, making temporary changes to the >> target-independent code is the best way until I understand how to best >> implement the final version. > > For purely personal hacks I'd go via Module::getTargetTriple myself, but then for personal hacks I probably wouldn't even bother checking the target. > > Cheers. > > Tim. >

...hen it reaches add() method of the pass manager. Can you help me figuring out what’s the problem please? here is my function int moduleToObjectFile(llvm::Module *module, std::string &srcname, llvm::LLVMContext &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() <<...

...gt; Can you help me figuring out what’s the problem please? here is my function >> >> >> int moduleToObjectFile(llvm::Module *module, std::string &srcname, llvm::LLVMContext &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);...

> It is simpler. There is not any Mach-O envelope. The platform linker > can directly read Mach-O files as well as llvm bit-code file (using > llvm bit-code file reader). > > > Not sure if/where the exact form of the Mach-O file that carries bit > > code is documented. Thanks for that. Yes, I see what you mean (no Mach-O envelope), yet there seems to be something