similar to: [LLVMdev] MachineOperand: Subreg defines and the Undef flag

On Jul 4, 2012, at 10:45 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > This question relates to the undef flag in the context of sub-register def > operands. > > 1) Firstly, the documentation (comments in the source code) says that in a > sub-register def operand, the "IsUndef" flag refers to the part of the > register that is not

Hi Jakob, Thanks for your reply. > > The <undef> flag goes on NewMI_1 because the virtual register B isn't live > before that instruction. > > But you probably shouldn't be doing this yourself. Your NewMI code isn't in > SSA form because B has multiple definitions. Just use a REG_SEQUENCE > instruction, and let the register allocator do the transformation

Hi Jakob, > New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 > are 32 bit virt. regs. > New_MI_2:: Vreg2 = COPY C:lo_sub_reg. > New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B > is a > 64 bit virt reg. I used this approach and it worked find until I hit, what I believe is, a bug in the register coalescer. When the register

On Jul 5, 2012, at 6:01 PM, "Pranav Bhandarkar" <pranavb at codeaurora.org> wrote: > Hi Jakob, > >> New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 >> are 32 bit virt. regs. >> New_MI_2:: Vreg2 = COPY C:lo_sub_reg. >> New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B >> is a >> 64 bit

> > > That sounds like a bug, probably adjustCopiesBackFrom needs to check > ACopyMI->isFullCopy(). > > Do you have a test case for this? > > Yes and No. Yes because the example is from a unit testcase that I have. No because it manifests itself only with my half baked pass that I was talking about earlier in this thread. Pranav -------------- next part --------------

On Jul 6, 2012, at 7:30 AM, Pranav D Bhandarkar <pranav.bhandarkar at utexas.edu> wrote: > That sounds like a bug, probably adjustCopiesBackFrom needs to check ACopyMI->isFullCopy(). > > Do you have a test case for this? > > > Yes and No. Yes because the example is from a unit testcase that I have. No because it manifests itself only with my half baked pass that I

This seems a very natural approach but I probably am having a trouble with the iterator invalidation. However, looking at other peephole optimizers passes, I couldn't see how to do this: #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, MBBI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) for

I'm writing a peephole pass and I'm done with the X86_64 instruction level detail work. But I'm having difficulty with the basic block surgery of replacing the old MachineInst. The peephole pass gets called per MachineFunction and then iterates over each MachineBasicBlock and in turn over each MachineInst. When it finds an instruction which should be replaced, it builds a new

<dag at cray.com> writes: > For reaching definitions I think simply tracking definitions via super > registers should be sufficient. Even if a definition defines a > subregister I can consider it to define the "most super" register. This > will be pessimistic for cases like x86 AH/AL, but I hardly care about > those at the moment. :) I did a big *facepalm*

On Apr 18, 2013, at 9:45 AM, dag at cray.com wrote: > I'm working on the post-regalloc dataflow engine I mentioned yesterday. > Currently I only need to track register operands. > > A MachineOperand has both a getReg() and a getSubReg() interface. For a > physical register operand, is getReg() guaranteed to be the "most super" > register with getSubReg()

On Apr 19, 2013, at 7:18 AM, <dag at cray.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >>> A MachineOperand has both a getReg() and a getSubReg() interface. >>> For a physical register operand, is getReg() guaranteed to be the >>> "most super" register with getSubReg() providing the specific >>> subregister

I'm working on the post-regalloc dataflow engine I mentioned yesterday. Currently I only need to track register operands. A MachineOperand has both a getReg() and a getSubReg() interface. For a physical register operand, is getReg() guaranteed to be the "most super" register with getSubReg() providing the specific subregister information for the operand? If so then for my current

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> A MachineOperand has both a getReg() and a getSubReg() interface. >> For a physical register operand, is getReg() guaranteed to be the >> "most super" register with getSubReg() providing the specific >> subregister information for the operand? If so then for my current >> purposes it seems I

Hi, While working on https://reviews.llvm.org/D79785, we wanted to define foldMemoryOperandImpl hook for Thumb1, that folds load, indirect call to direct call tLDRpci, tBLX -> tBL. This triggered an assertion error with expensive checks turned on in MachineVerifier because the newly created tBL insn by Thumb1InstrInfo::foldMemoryOperandImpl had memory operands of LoadMI attached by

I made the change to the BuildMI() call. Again, I don't think that matters. #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, OldMI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) I didn't completely understand your other proposed change: ​ for (MachineBasicBlock::iterator MBBI = MBB->begin();

Hi Quentin, I get following error from MachineVerifier: # End machine code for function f. *** Bad machine code: Missing mayLoad flag *** which comes from: // Check the MachineMemOperands for basic consistency. for (MachineMemOperand *Op : MI->memoperands()) { if (Op->isLoad() && !MI->mayLoad()) report("Missing mayLoad flag", MI); if (Op->isStore()

There are 11 BuildMI() functions in MachineInstrBuilder.h including four using the iterator and one using an instruction. But I just don't think that's it. The creation of the new instruction works fine (works fine with OldMI as well) and the new instruction is present in the assembly output. The problem is removing the old instruction correctly. > The loop header needs to be

Hi, It seems to me that the TwoAddressInstructionPass::runOnMachineFunction method has some problems when the tied destination register has a subReg. The two changes below improves the situation for me but I'm all new to this so I'm not sure how it's supposed to work. I'm running on 2.9. Any comments? @@ -1172,12 +1172,20 @@ bool

Dear R-Users, I used the box.tidwell () function of the car Package. When I used the following formula: semi.sub.in.mi1.boxtidwell_h<-box.tidwell(RENT_LG ~ I(age+1)+I(age2+1)+X06A + I(X08B+1) + I(X22+1) + I(X24+1) + X31A, ~B_YEAR + C_X01 + C_X14 + C_X19 + C_X29A +C_X21 + C_X23 + D_X12 + D_X17 + D_X18 + D_X25 + D_X27 + D_X30 + D_X32 + D_X35, data = semi.sub.in.mi1) everything is

Hi, I have a problem regarding sub-register definitions and LiveIntervals on our target. When a subregister is defined, other parts of the register are always left untouched - they are neither read or def:ed. It however seems that Codegen treats subregister definitions as somehow clobbering the whole register. The SSA-code looks like this after isel: (Reg0 and Reg1 are 16bit registers. Reg2,