search for: gettargetmachine

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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