search for: newvregs

In LiveIntervals::processImplicitDefs() we have this: for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg), UE = mri_->use_end(); UI != UE; ) { MachineOperand &RMO = UI.getOperand(); MachineInstr *RMI = &*UI; ++UI; MachineBasicBlock *RMBB = RMI->getParent(); if (RMBB == MBB) continue; const

> On Aug 24, 2015, at 4:46 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Here is the snippet that matters: > > void > InstrEmitter::AddRegisterOperand(MachineInstrBuilder &MIB, > SDValue Op, > unsigned IIOpNum, > const MCInstrDesc *II, >

Hi Ryan, > On Aug 24, 2015, at 6:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Quentin, > > I apologize for the spamming here but in getVR (where VReg is assigned an RC), it calls: > > const TargetRegisterClass *RC = TLI->getRegClassFor(Op.getSimpleValueType()); > VReg = MRI->createVirtualRegister(RC); > > My question is why is it using the

Quentin, This is the issue. Somewhere prior to the constrainRegClass, it's assigning the GPRBase sub class of GPR to the MOV instruction, so it can't constrain it to Base and hence has to add the COPY. Now I just need to find out why it is ignoring the TableGen defined GPRBase for the MOV MI in favor of it's sub class GPR. Thanks. On Mon, Aug 24, 2015 at 8:34 PM, Ryan Taylor

On Jul 17, 2009, at 7:57 AM, David Greene wrote: > In LiveIntervals::processImplicitDefs() we have this: > > for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg), > UE = mri_->use_end(); UI != UE; ) { > MachineOperand &RMO = UI.getOperand(); > MachineInstr *RMI = &*UI; > ++UI; > MachineBasicBlock *RMBB

Here is the instruction in question: multiclass AD<string asmstr, SDPatternOperator OpNode, RegisterClass srcAReg, RegisterClass dstReg, ValueType srcAType, ValueType dstType, Operand ImmOd, ImmLeaf imm_type> { def REG_REG : SetADInOut<asmstr, srcAReg, dstReg, [(set dstReg:$dstD, (OpNode srcAReg:$srcA))]>; def IMM_REG :

> On Aug 24, 2015, at 1:30 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm trying to do something like this: > > // Dst = NewVReg's reg class > // *II = MCInstrDesc > // IIOpNum = II Operand Num > > if (TRI->getCommonSubClass(DstRC, TRI->getRegClass(II->OpInfo[IIOpNum].RegClass)) == DstRC) > MRI->setRegClass(VReg, DstRC); >

1. MOV16Copy_IMM_REG is the instruction matched, sorry. AD is the multiclass. The IMM in my case is a global. So you can see that GPRBaseRegs, GPRBaseRegs sets the registerclass for both the src and dst operands, in this case (MOV16Copy_IMM_REG) it's the dst. 2. Yes I agree, it most likely would. Honestly, this comes across like a bug, or unintended feature. It's adding an extra COPY to

I have not tried 3.5, it's a significant amount of work to port from one version to the next though, I did not personally do the 3.4 to 3.6 porting. I agree though, it was very strange that it suddenly just changed behavior. It looks like to me that InstrEmitter.cpp:getVR is the one assigning the virtual register no? Though this code in CreateVirtualRegisters: const TargetRegisterClass *RC

AddRegisterOperand calls getVR and yes, I think an IMPLICIT_DEF is being generated. On Tue, Aug 25, 2015 at 2:40 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > On Aug 25, 2015, at 11:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I have not tried 3.5, it's a significant amount of work to port from one > version to the next though, I did not

BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG <ga:@a+1>[TF=1]; GPRRegs:%vreg0 %vreg1<def> = COPY %vreg0; PTRRegs:%vreg1 GPRRegs:%vreg0 Send_iii %NULLR0, %vreg1<kill>, 1, 1, 1, 1, 0; PTRRegs:%vreg1 RetRA This is what I get. This is what I'd like to get: BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG

> On Aug 22, 2015, at 9:10 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > One last question regarding this please. > > Why aren't we simply changing the register class in AddRegisterOperand instead of building a new COPY? I admit I haven't thought this out but for my test cases so far this works just fine and reduces the number of ASM mov instructions that are

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On

On May 27, 2008, at 5:36 PM, David Greene wrote: > I've been playing around with spillers and found that the > SimpleSpiller fails > badly on a particular code. > > The problem arises because SimpleSpiller does the test > VRM.isAssignedReg(virtReg) which is implemented as: > > 00183 bool isAssignedReg(unsigned virtReg) const { > 00184 if

...reg25 Remat created 1 dead defs. Deleting dead def 344r %vreg25<def,dead> = LDIWRdK 2; DLDREGS:%vreg25 0 registers to spill after remat. <----- NO SPILL My question is how could I detect this behaviour so i don't get any false positives? I've thought of checking if the variable NewVRegs increases in size after the call to the spill() method meaning that a remat happened, but I don't know if this is always correct in all situation and another important thing, are there any more cases where a spill could be avoided getting more false positives? Thanks for your help. -----------...

Hi Quentin and llvm-dev, I've got a regalloc-related question that you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> *

Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time). Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a

On Nov 30, 2011, at 12:17 PM, Borja Ferrer wrote: > Thanks for all the hints Jakob, I've added the following piece of code after the spill code handling inside selectOrSplit() (ignoring some control logic): > > for (LiveIntervals::const_iterator I = LIS->begin(), E = LIS->end(); I != E; > ++I) > { > unsigned VirtReg = I->first; > if

...1 dead defs. > Deleting dead def 344r %vreg25<def,dead> = LDIWRdK 2; DLDREGS:%vreg25 > 0 registers to spill after remat. <----- NO SPILL > > My question is how could I detect this behaviour so i don't get any false positives? I've thought of checking if the variable NewVRegs increases in size after the call to the spill() method meaning that a remat happened, but I don't know if this is always correct in all situation and another important thing, are there any more cases where a spill could be avoided getting more false positives? The spiller will be calling into...