search for: tii

...eGen is layered on top of Target. What do you think? That distinction is very useful, and we don't violate that anywhere AFAIK. I also agree that Target should not depend on CodeGen because we want to be able to access MC functionality without pulling in all of CodeGen. However, the TRI and TII classes only exist to service CodeGen. Most hooks take MachineInstr or MachineFunction arguments, making them impossible to implement without pulling in CodeGen. The implementation files for TRI and TII provide default implementations for a few hooks, but these defaults cannot depend on CodeGen. W...

...rg> > wrote: > > > > /// Optimizations after all the reg selections and spills are done. > > void InlineSpiller::postOptimization() { HSpiller.hoistAllSpills(); > > } > > > > Seems a problematic function to me, as hoistAllSpills() uses > > TII.storeRegToStackSlot() to insert new spills. > > > > The problem is, TII.storeRegToStackSlot is allowed to create new virtual > > registers, which can not be allocated a range as this whole thing is > called > > _after_ all reg selection is complete. > > > > If...

...r I){ const BasicBlock* LLVM_BB = Pred->getBasicBlock(); MachineBasicBlock * MBB = MF.CreateMachineBasicBlock(LLVM_BB); // create a MBB MBB->setNumber(19880616); // set the number of MBB to be 19880616 which is used as an ID Pred->addSuccessor(MBB); const TargetInstrInfo *TII = MF.getTarget().getInstrInfo(); DebugLoc dl; // CALLpcrel32 abort BuildMI(MBB,dl,TII->get(X86::CALLpcrel32)).addExternalSymbol("abort"); // JNE_4 error_label BuildMI(MBB,dl,TII->get(X86::JNE_4)).addExternalSymbol("error_label"); // MOV32ri %eax, 0 Bui...

...of the 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->CreateMac...

...t; +let usesCustomDAGSchedInserter = 1 in { > + let Uses = [CR0] in { > + let Uses = [R0] in > + def ATOMIC_LOAD_ADD_I32 : Pseudo< > > The "let Uses = [R0]" is not needed. The pseudo instruction will be > expanded like this later: > > + BuildMI(BB, TII->get(is64bit ? PPC::LDARX : PPC::LWARX), dest) > + .addReg(ptrA).addReg(ptrB); > + BuildMI(BB, TII->get(is64bit ? PPC::ADD4 : PPC::ADD8), PPC::R0) > + .addReg(incr).addReg(dest); > + BuildMI(BB, TII->get(is64bit ? PPC::STDCX : PPC::STWCX)) > + .addReg(PP...

...can work on them. To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. I started with branch instructions:     const TargetMachine &TM = MF.getTarget();     const MCInstrInfo *TII = TM.getMCInstrInfo();     DebugLoc DL;     BuildMI(BB, BB.end(), DL, TII->get(ARM::B)).addMBB(trgBlock); these are working fine. When creating an compare instruction like cmp r0, 1 with:      BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8),0).addImm(1); I get the following...

...d? >> What level of codegen are you working at? There are various mechanisms that can be applied, depending on exactly what the constraints are that you need to preserve. >> >> —Owen > I have two machine instructions that I need to be together. > > BuildMI(MBB, I, DL, TII.get(Mips::LiRxImmAlignX16), V0) > .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI); > BuildMI(MBB, I, DL, TII.get(Mips::AddiuRxPcImmX16), V1) > .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO); > > It's in Mips16ISelDagToDag.cpp > > these two...

...p(MI, BB); + } } *************** *** 3114,3119 **** --- 3142,3352 ---- return BB; } + MachineBasicBlock* SparcTargetLowering:: + emitEHSjLjLongJmp(MachineInstr *MI, + MachineBasicBlock *MBB) const + { + DebugLoc DL = MI->getDebugLoc(); + const TargetInstrInfo *TII = Subtarget->getInstrInfo(); + + MachineFunction *MF = MBB->getParent(); + MachineRegisterInfo &MRI = MF->getRegInfo(); + MachineInstrBuilder MIB; + + // Memory Reference + MachineInstr::mmo_iterator MMOBegin = MI->memoperands_begin(); + MachineInstr::mmo_iterator MMOEnd...

...There are various mechanisms > that can be applied, depending on exactly what the constraints are that you > need to preserve. > >>> > >>> -Owen > >> I have two machine instructions that I need to be together. > >> > >> BuildMI(MBB, I, DL, TII.get(Mips::LiRxImmAlignX16), V0) > >> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI); > >> BuildMI(MBB, I, DL, TII.get(Mips::AddiuRxPcImmX16), V1) > >> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO); > >> > >> It's...

/// Optimizations after all the reg selections and spills are done. void InlineSpiller::postOptimization() { HSpiller.hoistAllSpills(); } Seems a problematic function to me, as hoistAllSpills() uses TII.storeRegToStackSlot() to insert new spills. The problem is, TII.storeRegToStackSlot is allowed to create new virtual registers, which can not be allocated a range as this whole thing is called _after_ all reg selection is complete. If I'm right in this, I do not see how the in-tree target AMD...

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

>> // Increment loop variable and jmp >> BuildMI(*MBB_erase, MBB_erase->end(), db, >> TII->get(X86::ADD64ri32),reg).addReg(reg).addImm(8); > > It looks like this instruction is defining virtual register "reg" the second time. Thx for your answer... Why would it define it again? I just want to use this register and add something to it... Cheers

...t; To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. > I started with branch instructions: > > const TargetMachine &TM = MF.getTarget(); > const MCInstrInfo *TII = TM.getMCInstrInfo(); > DebugLoc DL; > BuildMI(BB, BB.end(), DL, TII->get(ARM::B)).addMBB(trgBlock); > > these are working fine. > When creating an compare instruction like cmp r0, 1 with: > > BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8),0)....

...serter = 1 in { >> + let Uses = [CR0] in { >> + let Uses = [R0] in >> + def ATOMIC_LOAD_ADD_I32 : Pseudo< >> >> The "let Uses = [R0]" is not needed. The pseudo instruction will be >> expanded like this later: >> >> + BuildMI(BB, TII->get(is64bit ? PPC::LDARX : PPC::LWARX), dest) >> + .addReg(ptrA).addReg(ptrB); >> + BuildMI(BB, TII->get(is64bit ? PPC::ADD4 : PPC::ADD8), PPC::R0) >> + .addReg(incr).addReg(dest); >> + BuildMI(BB, TII->get(is64bit ? PPC::STDCX : PPC::STWCX)) >&g...

...vel of codegen are you working at? There are various mechanisms that can be applied, depending on exactly what the constraints are that you need to preserve. >>> >>> —Owen >> I have two machine instructions that I need to be together. >> >> BuildMI(MBB, I, DL, TII.get(Mips::LiRxImmAlignX16), V0) >> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI); >> BuildMI(MBB, I, DL, TII.get(Mips::AddiuRxPcImmX16), V1) >> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO); >> >> It's in Mips16ISelDagToDag.cpp...

...also doesn't work. After some research I found the following thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8)).addReg(ARM::R0).addImm(1).add(predOps(ARMCC::AL); But how do I know how many and which condition codes each instruction needs? [MOVi takes 3 operands relating to the condition code (all after the immediate)] There is no info about that in the ARMInstrThumb.td file. -Julius...

...et. What do you think? > > That distinction is very useful, and we don't violate that anywhere AFAIK. > > I also agree that Target should not depend on CodeGen because we want to be able to access MC functionality without pulling in all of CodeGen. > > However, the TRI and TII classes only exist to service CodeGen. Most hooks take MachineInstr or MachineFunction arguments, making them impossible to implement without pulling in CodeGen. The implementation files for TRI and TII provide default implementations for a few hooks, but these defaults cannot depend on CodeGen. &g...

...ere are various mechanisms >> that can be applied, depending on exactly what the constraints are that you >> need to preserve. >>>>> -Owen >>>> I have two machine instructions that I need to be together. >>>> >>>> BuildMI(MBB, I, DL, TII.get(Mips::LiRxImmAlignX16), V0) >>>> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI); >>>> BuildMI(MBB, I, DL, TII.get(Mips::AddiuRxPcImmX16), V1) >>>> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO); >>>> >>...

...WAP, VTs, Ops, 3); } /// LowerSELECT_CC - Lower floating point select_cc's into fsel instruction when @@ -3980,59 +3919,198 @@ PPCTargetLowering::EmitInstrWithCustomInserter(MachineInstr *MI, MachineBasicBlock *BB) { const TargetInstrInfo *TII = getTargetMachine().getInstrInfo(); - assert((MI->getOpcode() == PPC::SELECT_CC_I4 || - MI->getOpcode() == PPC::SELECT_CC_I8 || - MI->getOpcode() == PPC::SELECT_CC_F4 || - MI->getOpcode() == PPC::SELECT_CC_F8 || - MI->getOpcode() == PPC::SELECT_C...

On Wed, Oct 31, 2012 at 09:13:43PM +0100, Bjorn De Sutter wrote: > Hi all, > > I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we