search for: gettargetmachine

Displaying 20 results from an estimated 48 matches for "gettargetmachine".

2013 May 17
3
[LLVMdev] subtle issue with soft-float and new attribute scheme (possibly an issue with other attributes)
...d to be that in that case -msoft-float had no effect because those attributes where not preserved in the IL. ) Then if you run llc and say -soft-float, what happens is that the code generator will compile everything as soft-float, but the value of the following will be false in XXXISelLowering getTargetMachine().Options.UseSoftFloat When the constructor for XXXISelLowering is called, TM.Options.UseSoftFloat will be true. What is interesting is that code for "make check" won't have any of the new attributes there so it will work as before. I was seeing this behavior and could not figure...
2013 May 18
0
[LLVMdev] subtle issue with soft-float and new attribute scheme (possibly an issue with other attributes)
...-msoft-float had no effect because those > attributes where not preserved in the IL. ) > > Then if you run llc and say -soft-float, what happens is that the code > generator will compile everything as soft-float, but the value of the > following will be false in XXXISelLowering > getTargetMachine().Options.UseSoftFloat > > When the constructor for XXXISelLowering is called, TM.Options.UseSoftFloat > will be true. > > What is interesting is that code for "make check" won't have any of the new > attributes there so > it will work as before. > > I was s...
2016 Feb 05
4
MCJit Runtine Performance
Hi Morten, Something else just occurred to me: can you share your EngineBuilder configuration lines? (http://llvm.org/docs/doxygen/html/classllvm_1_1EngineBuilder.html) In particular - are you explicitly setting the optimization level? The old JIT may have had a different default. - Lang. Sent from my iPad > On Feb 4, 2016, at 10:54 PM, Jim Grosbach via llvm-dev <llvm-dev at
2014 Apr 29
2
[LLVMdev] MIPS n64 ABI and non-PIC
Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like: if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { } around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can't find any discussion of it anywhere. I ran into this when trying to see why --relocation-model=static had no effect on the output. I&...
2013 May 18
1
[LLVMdev] subtle issue with soft-float and new attribute scheme (possibly an issue with other attributes)
...ect because those >> attributes where not preserved in the IL. ) >> >> Then if you run llc and say -soft-float, what happens is that the code >> generator will compile everything as soft-float, but the value of the >> following will be false in XXXISelLowering >> getTargetMachine().Options.UseSoftFloat >> >> When the constructor for XXXISelLowering is called, TM.Options.UseSoftFloat >> will be true. >> >> What is interesting is that code for "make check" won't have any of the new >> attributes there so >> it will work...
2008 Feb 15
1
[LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build
...amed-tag> if (GlobalAddressSDNode *G = dyn_cast<GlobalAddressSDNode>(Callee)) { // We should use extra load for direct calls to dllimported functions in // non-JIT mode. // it get's into here if ((IsTailCall || !Is64Bit || // both these are false getTargetMachine().getCodeModel() != CodeModel::Large) // this is false && !Subtarget->GVRequiresExtraLoad(G->getGlobal(), // this is short circuited away getTargetMachine(), true)) Callee = DAG.getTargetGlobalAddress(G->getGlobal(), g...
2017 Apr 09
2
Possible stack corruption during call to JITSymbol::getAddress()
...r)::ModuleSetHandleT ModuleHandle; KaleidoscopeJIT() : TM(EngineBuilder().selectTarget()), DL(TM->createDataLayout()), CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); } TargetMachine &getTargetMachine() { return *TM; } ModuleHandle addModule(std::unique_ptr<Module> M) { // Build our symbol resolver: // Lambda 1: Look back into the JIT itself to find symbols that are part of // the same "logical dylib". // Lambda 2: Search for externa...
2017 Apr 17
2
Possible stack corruption during call to JITSymbol::getAddress()
...> : TM(EngineBuilder().selectTarget()), >> DL(TM->createDataLayout()), >> CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { >> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >> } >> >> TargetMachine &getTargetMachine() { return *TM; } >> >> ModuleHandle addModule(std::unique_ptr<Module> M) { >> // Build our symbol resolver: >> // Lambda 1: Look back into the JIT itself to find symbols that >> are part of >> // the same "logical...
2014 May 02
2
[LLVMdev] MIPS n64 ABI and non-PIC
...randon Hill > *Sent:* 29 April 2014 22:35 > *To:* llvmdev at cs.uiuc.edu > *Subject:* [LLVMdev] MIPS n64 ABI and non-PIC > > > > Has anyone experimented with generating non-PIC for MIPS64 and the n64 > ABI? Currently MipsISelLowering.cpp uses conditions like: > > if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { > > } > > > > around any PIC code generation. Is generating non-PIC just untested, or > is it known not to work? I can't find any discussion of it anywhere. I ran > into this when trying to see why --relocation-model=...
2017 Apr 20
2
Possible stack corruption during call to JITSymbol::getAddress()
...et()), >>>> DL(TM->createDataLayout()), >>>> CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { >>>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >>>> } >>>> >>>> TargetMachine &getTargetMachine() { return *TM; } >>>> >>>> ModuleHandle addModule(std::unique_ptr<Module> M) { >>>> // Build our symbol resolver: >>>> // Lambda 1: Look back into the JIT itself to find symbols that >>>> are part of >>>...
2017 May 01
1
Possible stack corruption during call to JITSymbol::getAddress()
...DataLayout()), >>>>>> CompileLayer(ObjectLayer, SimpleCompiler(*TM)) { >>>>>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >>>>>> } >>>>>> >>>>>> TargetMachine &getTargetMachine() { return *TM; } >>>>>> >>>>>> ModuleHandle addModule(std::unique_ptr<Module> M) { >>>>>> // Build our symbol resolver: >>>>>> // Lambda 1: Look back into the JIT itself to find symbols >>>&g...
2014 Dec 08
2
[LLVMdev] Virtual register problem in X86 backend
...stack to zero at the end of each function. Here is my code: MachineBasicBlock * X86TargetLowering::EmitBURNSTACKWithCustomInserter( MachineInstr *MI, MachineBasicBlock *MBB) const { DebugLoc db = MI->getDebugLoc(); const TargetInstrInfo *TII = getTargetMachine().getInstrInfo(); const BasicBlock *LLVM_BB = MBB->getBasicBlock(); MachineFunction *F = MBB->getParent(); // Create all the basicblocks MachineBasicBlock *MBB_cond = F->CreateMachineBasicBlock(LLVM_BB); MachineBasicBlock *MBB_erase = F->CreateMachineBasicBlock(LLVM...
2013 Oct 27
0
[LLVMdev] Why is the loop vectorizer not working on my function?
...(right now, the old JIT interface). There is no need for other targets. Maybe it would be good to ask specific questions: How do I get the triple for the native target? How do I setup the target transform info pass? I guess I need the target machine for all of this. 'opt' defines the GetTargetMachine() function which takes a Triple (my native triple). It calls GetTargetOptions(). This function, as implemented in 'opt', looks very static to me and surely doesn't fit all machines. Do I need this for my setup? Frank On 26/10/13 20:43, Arnold Schwaighofer wrote: > Hi Frank, &gt...
2013 Oct 27
3
[LLVMdev] Why is the loop vectorizer not working on my function?
...sets up its pass pipeline. You need to have your/the target add the target’s analysis passes: opt.cpp: PassManager Passes; … // Add target library info and data layout. Triple ModuleTriple(M->getTargetTriple()); TargetMachine *Machine = 0; if (ModuleTriple.getArch()) Machine = GetTargetMachine(Triple(ModuleTriple)); OwningPtr<TargetMachine> TM(Machine); // Add internal analysis passes from the target machine. if (TM.get()) TM->addAnalysisPasses(Passes); // <<< … TM->addAnalysisPasses(FPManager); Here is what the target does: void X86TargetMachine::ad...
2008 Feb 15
0
[LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build
On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by
2007 Dec 11
0
[LLVMdev] Exception handling in JIT
...nager(); > @@ -318,9 +403,14 @@ > MemMgr->AllocateGOT(); > DOUT << "JIT is managing a GOT\n"; > } > + if (ExceptionHandling) > + DE = new DwarfJITEmitter(*this, *jit.getTargetData(), > + jit.getTargetMachine()); > + Please don't add getTargetMachine() to jit. MachineCodeEmitter can keep a reference to MachineFunction or something like that. > } > ~JITEmitter() { > delete MemMgr; > + if (ExceptionHandling) delete DE; > } > > JITResolver &am...
2007 Dec 10
2
[LLVMdev] Exception handling in JIT
Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the
2007 Sep 11
0
[LLVMdev] RFC: Tail call optimization X86
...t;(Op.getOperand(3))- >getValue() != 0; + SDOperand Callee = Op.getOperand(4); + //unsigned NumOps = (Op.getNumOperands() - 5) / 2; + + // Analyze operands of the call, assigning locations to each operand. + SmallVector<CCValAssign, 16> ArgLocs; + CCState CCInfo(CC, isVarArg, getTargetMachine(), ArgLocs); + CCInfo.AnalyzeCallOperands(Op.Val, CC_X86_32_TailCall); + if (isTailCall && + IsEligibleForTailCallElimination(Op, DAG,CC, Callee) && + PerformTailCallOpt) { IsEligibleForTailCallElimination() should be a target hook. This way TargetLowering::LowerCall...
2014 Oct 28
2
[LLVMdev] Problem in X86 backend (again)
...r... The goal of this code is to erase the stack in the epilogue of a function: MachineBasicBlock * X86TargetLowering::EmitBURNSTACKWithCustomInserter( MachineInstr *MI, MachineBasicBlock *MBB) const { MBB->getParent()->dump(); DebugLoc db = MI->getDebugLoc(); const TargetInstrInfo *TII = getTargetMachine().getInstrInfo(); const BasicBlock *LLVM_BB = MBB->getBasicBlock(); MachineFunction *F = MBB->getParent(); // Create all the basicblocks MachineBasicBlock *MBB_cond = F->CreateMachineBasicBlock(LLVM_BB); MachineBasicBlock *MBB_erase = F->CreateMachineBasicBlock(LLVM_BB); MachineBasicBlo...
2007 Sep 06
2
[LLVMdev] RFC: Tail call optimization X86
Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in