search for: copyregtoreg

...t; = INSERT_SUBREG %reg1045, %reg1044<kill>, 4 %reg1045:sub_32bit<def> = COPY %reg1044<kill> %reg1050:ssub_0<def> = EXTRACT_SUBREG %reg1060:dsub_1<kill>, ssub_0 %reg1050:ssub_0<def> = COPY %reg1060:ssub_2<kill> It will also replace the TargetInstrInfo::copyRegToReg hook when copying virtual registers: %reg1050 = COPY %reg1044<kill> It will be lowered with a TII.copyRegToReg() call in LowerSubregsInstructionPass (which may need renaming). Why? 1. The new function CoalescerPair::isMoveInstr() can correctly determine if a MachineInstr is a (partial)...

...reg1044<kill>, 4 > %reg1045:sub_32bit<def> = COPY %reg1044<kill> > > %reg1050:ssub_0<def> = EXTRACT_SUBREG %reg1060:dsub_1<kill>, ssub_0 > %reg1050:ssub_0<def> = COPY %reg1060:ssub_2<kill> > > It will also replace the TargetInstrInfo::copyRegToReg hook when copying virtual registers: > > %reg1050 = COPY %reg1044<kill> > > It will be lowered with a TII.copyRegToReg() call in LowerSubregsInstructionPass (which may need renaming). Ok. An immediate concern is this will make it harder to understand machine instructions. For...

Hi, The PHI elimination pass calls the function copyRegToReg for copy placement and then later tries to setkill to the temporary virtual register used in copy placement. For this setkill action it looks only in one instruction (last instruction for copyRegToReg) for virtual register with no use. My target has only one register and I can't do copyRegT...

Hey, guys, I am creating some move instructions with MRegisterInfo::copyRegToReg. How do I get a pointer to the instruction that I just created? Is there a way to do something like: // mbb is MachineBasicBlock, reg_info is MRegisterInfo MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); reg_info->copyRegToReg(mbb, iter, dst, src, rc); iter--; (???) MachineIns...

copyRegToReg() always insert the move instruction before "iter". Just use prior(iter) after the insertion to reference the newly created move instruction. Evan On Feb 21, 2007, at 11:17 PM, Fernando Magno Quintao Pereira wrote: > > Hey, guys, I am creating some move instructions with >...

> 1. copyRegToReg() won't be able to use register classes to pick a copy opcode. For instance, an XMM register will no longer be copied by MOVSS or MOVSD. Given just the physical register, MOVAPS will be used. Is that a problem? I haven't had time to really look into it, but have been playing around with th...

...t;> > > That means, it gets converted to > > dst = src; > > dst = dst + 1; > > > > Right ? > > > > - Sanjiv > > > Yes, I believe the two address instruction pass performs exactly this > transformation. > Thanks. How do I communicate if my CopyRegToReg instruction clobbers a register of another register class? Is it through let Defs = [REG] { ... } while defining the instr pattern? - Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > htt...

...unsigned dst ) { MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); const TargetRegisterClass *rc = mf.getSSARegMap()->getRegClass(dst); const MRegisterInfo * reg_info = mf.getTarget().getRegisterInfo(); reg_info->copyRegToReg(mbb, iter, dst, src, rc); } But the getRegClass method seems to expect a virtual register. Could someone fix this code for me? I could not find an example in the source of LLVM. Thank you very much, Fernando

...Magno Quintao Pereira wrote: > > > MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); > > const TargetRegisterClass *rc = mf.getSSARegMap()->getRegClass(dst); > > const MRegisterInfo * reg_info = mf.getTarget().getRegisterInfo(); > > reg_info->copyRegToReg(mbb, iter, dst, src, rc); > > } > > > > But the getRegClass method seems to expect a virtual register. Could > > someone fix this code for me? I could not find an example in the source of > > LLVM. > > You can't do it with this information. In some higher co...

...suming that a2, b2 come from block B_s, at the end of block B_s I would have to add the permutation: (r1, r2) <- perm (r2, r1) which I can implement with six Xor instructions. Well, I would like to get some comments about the best way to implement this in LLVM. Should I change the function "copyRegToReg" in X86RegisterInfo.cpp? I am afraid this function is used in other situations where copy instructions are expected. On the other hand, if I create a separate function, and change PHIElimination.cpp, I am afraid to lose retargability. Also, if possible, I would like to know if, besides the so...

...nstruction. They are allocatable also. br i1 %if_cond, label %then, label %else then: %x1 = fptosi float %y1 to i32 br label %endif else: %x2 = fptosi float %y2 to i32 br label %endif endif: %x3 = phi i32 [%x1, %then], [%x2, %else] PNE::LowerAtomiPHINode() fails because TargetInstrInfo::copyRegToReg() doesn't support the copy of this type of register. Most registers of this hardware are f32. These two special register of type i32 are provided to relative index the other f32 registers. The value of these i32 registers can only be written by a FP-to-INT conversion instruction. But these two...

...entially cute. Note that most copy instructions inserted by the phi elimination phase are coallesced away: replacing them with xor instructions would prevent that. > Well, I would like to get some comments about the best way to implement > this in LLVM. Should I change the function "copyRegToReg" in > X86RegisterInfo.cpp? No, certainly not. > I am afraid this function is used in other > situations where copy instructions are expected. Yup, that it would. > On the other hand, if I create a separate function, and change > PHIElimination.cpp, I am afraid to lose ret...

...oes not causes incorrect allocation: for(MRegisterInfo::regclass_iterator rcii = reg_info->regclass_begin(), rcie = reg_info->regclass_end(); rcii != rcie; ++rcii) { if( (*rcii)->contains(dst) ) { rc = * rcii; } } reg_info->copyRegToReg(mbb, iter, dst, src, rc); } Fernando > > You can't do it with this information. In some higher context you should > > have information about what register class the physreg is to be > > interpreted as. Physregs can be in multiple register classes. > > > > All o...

...to save i64. llvm finds I have i64 GPR register. It will automatically decide not to expand i64 to two i32. 2. I guess I need a special pseudo instruction to move between GPR32 and GPR64. How to move R0, R1 to T1( R2, R3 pair). and don't convert two i32 to i64? Could I use MyTargetInstrInfo::copyRegToReg() to handle this logic issue? 3. Maybe I can study INSERT_SUBREG/EXTRACT_SUBREG at X86 porting file. I will do some research more deeply. I think the best way is that TableGen has register pair TypeProfile feature. :( But I find i64 data will not be ex --- 09年2月20日，周五, Evan Cheng <echen...

...register. It will automatically decide not to expand > i64 to two i32. > > 2. I guess I need a special pseudo instruction to move between GPR32 > and GPR64. > How to move R0, R1 to T1( R2, R3 pair). and don't convert two i32 to > i64? > Could I use MyTargetInstrInfo::copyRegToReg() to handle this logic > issue? No. copyRegToReg only supports copying registers of the same (or compatible register classes). > > > 3. Maybe I can study INSERT_SUBREG/EXTRACT_SUBREG at X86 porting file. Yes. > > > I will do some research more deeply. I think the best w...

...rted to >>> dst = src; >>> dst = dst + 1; >>> >>> Right ? >>> >>> - Sanjiv >>> >> Yes, I believe the two address instruction pass performs exactly this >> transformation. >> > Thanks. > How do I communicate if my CopyRegToReg instruction clobbers a > register > of another register class? Is it through let Defs = [REG] { ... } > while > defining the instr pattern? That won't work. You don't know what physical registers are clobbered until you know the register assignments, right? One possibili...

...enerated. The default generation method seems to be to put the move instruction at the end of the preceding basic block related to that specific phi node, but I need it to place the move before some pseudo instructions that must be at the end of certain flow control basic blocks. I'm looking at copyRegToReg as a possible location on where to implement this modification, but I can't figure out how to determine if the origination of the move instruction to be generated is from a PHI node or a normal move operation. Any help would be useful in figuring this out. Thanks, Micah Villmow Systems...

...un, 2 Jul 2006, Fernando Magno Quintao Pereira wrote: > MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); > const TargetRegisterClass *rc = mf.getSSARegMap()->getRegClass(dst); > const MRegisterInfo * reg_info = mf.getTarget().getRegisterInfo(); > reg_info->copyRegToReg(mbb, iter, dst, src, rc); > } > > But the getRegClass method seems to expect a virtual register. Could > someone fix this code for me? I could not find an example in the source of > LLVM. You can't do it with this information. In some higher context you should have information...

...; , SDTIntBinOp , [SDNPCommutative, SDNPAssociative]>; ... and assumed it was sufficient, since I saw no other targets making special arrangements. I see no obvious (to me, anyway 8^) "copy instruction" property. The insn in question is generated by copyRegToReg(), and satisfies the isMoveInstr() predicate. G

...label %then, label %else > then: > %x1 = fptosi float %y1 to i32 > br label %endif > else: > %x2 = fptosi float %y2 to i32 > br label %endif > endif: > %x3 = phi i32 [%x1, %then], [%x2, %else] > > PNE::LowerAtomiPHINode() fails because > TargetInstrInfo::copyRegToReg() doesn't support the copy of this > type of register. > > Most registers of this hardware are f32. These two special register > of type i32 are provided to relative index the other f32 registers. > The value of these i32 registers can only be written by a FP-to-INT >...