search for: newvreg

...I != UE; ) { MachineOperand &RMO = UI.getOperand(); MachineInstr *RMI = &*UI; ++UI; MachineBasicBlock *RMBB = RMI->getParent(); if (RMBB == MBB) continue; const TargetRegisterClass* RC = mri_->getRegClass(Reg); unsigned NewVReg = mri_->createVirtualRegister(RC); MachineInstrBuilder MIB = BuildMI(*RMBB, RMI, RMI->getDebugLoc(), tii_->get(TargetInstrInfo::IMPLICIT_DEF), NewVReg); (*MIB).getOperand(0).setIsUndef(); RMO.setReg(NewVReg); RMO.setIsUndef();...

...{ > const TargetRegisterClass *DstRC = nullptr; > if (IIOpNum < II->getNumOperands()) > DstRC = TRI->getAllocatableClass(TII->getRegClass(*II,IIOpNum,TRI,*MF)); > if (DstRC && !MRI->constrainRegClass(VReg, DstRC, MinRCSize)) { > unsigned NewVReg = MRI->createVirtualRegister(DstRC); > if (TRI->getCommonSubClass(DstRC, > TRI->getRegClass(II->OpInfo[IIOpNum].RegClass)) What I was saying was this II->OpInfo[IIOpNum].RegClass looks to return DstRC at first glance. What you want is TRI->getRegClass(VReg)....

...> Thanks. > > On Mon, Aug 24, 2015 at 8:34 PM, Ryan Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote: > Quentin, > > It looks like firstCommonClass is returning a nullptr, which is odd since the MOV should be using GPRBase (GPR and Base) and the NewVReg class is Base. Maybe the ISel has decided to select the sub class GPR from GPRBase and hence GPR != Base and so the constrainRegClass is failing. > > Using the MI Op's reg class and comparing it directly to the NewVReg class would eliminate this possible issue and should produce more...

...the MOV MI in favor of it's sub class GPR. Thanks. On Mon, Aug 24, 2015 at 8:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Quentin, > > It looks like firstCommonClass is returning a nullptr, which is odd > since the MOV should be using GPRBase (GPR and Base) and the NewVReg class > is Base. Maybe the ISel has decided to select the sub class GPR from > GPRBase and hence GPR != Base and so the constrainRegClass is failing. > > Using the MI Op's reg class and comparing it directly to the NewVReg > class would eliminate this possible issue and should...

...Operand &RMO = UI.getOperand(); > MachineInstr *RMI = &*UI; > ++UI; > MachineBasicBlock *RMBB = RMI->getParent(); > if (RMBB == MBB) > continue; > const TargetRegisterClass* RC = mri_->getRegClass(Reg); > unsigned NewVReg = mri_->createVirtualRegister(RC); > MachineInstrBuilder MIB = > BuildMI(*RMBB, RMI, RMI->getDebugLoc(), > tii_->get(TargetInstrInfo::IMPLICIT_DEF), NewVReg); > (*MIB).getOperand(0).setIsUndef(); > RMO.setReg(NewVReg); >...

...def GPRBaseRegs: RegisterClass<"us", [i32], i32, (add BaseRegs, GPRRegs)>; >> >> This is not the issue I think. It seems that it's first choosing the >> subclass of GPRRegs for VReg but it then needs the dst in BaseRegs so it >> creates a new virtual reg (NewVReg) with BaseRegsClass and generates a COPY >> from GPRRegs to BaseRegsClass. >> >> 1. Why is it choosing the subclass for VReg instead of GPRBaseRegs? >> >> >> To answer this question, you need to track down the creation of VReg. I >> am guessing you want to...

> 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); > else > BuildMI(... TargetOpcode::COPY...) > > Th...

...s<"us", [i32], i32, (add BaseRegs, >>> GPRRegs)>; >>> >>> This is not the issue I think. It seems that it's first choosing the >>> subclass of GPRRegs for VReg but it then needs the dst in BaseRegs so it >>> creates a new virtual reg (NewVReg) with BaseRegsClass and generates a COPY >>> from GPRRegs to BaseRegsClass. >>> >>> 1. Why is it choosing the subclass for VReg instead of GPRBaseRegs? >>> >>> >>> To answer this question, you need to track down the creation of VReg. I >>...

...[i32], i32, (add BaseRegs, >>>> GPRRegs)>; >>>> >>>> This is not the issue I think. It seems that it's first choosing the >>>> subclass of GPRRegs for VReg but it then needs the dst in BaseRegs so it >>>> creates a new virtual reg (NewVReg) with BaseRegsClass and generates a COPY >>>> from GPRRegs to BaseRegsClass. >>>> >>>> 1. Why is it choosing the subclass for VReg instead of GPRBaseRegs? >>>> >>>> >>>> To answer this question, you need to track down the crea...

...seRegs, >>>>> GPRRegs)>; >>>>> >>>>> This is not the issue I think. It seems that it's first choosing the >>>>> subclass of GPRRegs for VReg but it then needs the dst in BaseRegs so it >>>>> creates a new virtual reg (NewVReg) with BaseRegsClass and generates a COPY >>>>> from GPRRegs to BaseRegsClass. >>>>> >>>>> 1. Why is it choosing the subclass for VReg instead of GPRBaseRegs? >>>>> >>>>> >>>>> To answer this question, you nee...

...>>> GPRRegs)>; >>>>>> >>>>>> This is not the issue I think. It seems that it's first choosing the >>>>>> subclass of GPRRegs for VReg but it then needs the dst in BaseRegs so it >>>>>> creates a new virtual reg (NewVReg) with BaseRegsClass and generates a COPY >>>>>> from GPRRegs to BaseRegsClass. >>>>>> >>>>>> 1. Why is it choosing the subclass for VReg instead of GPRBaseRegs? >>>>>> >>>>>> >>>>>> To answe...

...ass 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 being produced. > > For example, instead of BuildMI(..., TII->get(TargetOpcode::COPY), NewVReg).addReg(VReg), use something like MRI->setRegClass(VReg, MRI->getRegClass(NewVReg)) ? The problem is that the old register class and the new one may not intersect. I do not know exactly what makes us create a new vreg w.r.t., but probably if the class is not identical we create one. You can...

...t2PhysMap[virtReg] = physReg; 00154 } Note that this doesn't clear the stack slot or remat mappings. In the particular code I'm looking at, linear scan spills an interval and one of the intervals created (%reg1631) gets mark as rematerializable by LiveIntervals: 00984 if (CreatedNewVReg) { 00985 if (DefIsReMat) { 00986 vrm.setVirtIsReMaterialized(NewVReg, ReMatDefMI/*, CanDelete*/); 00987 if (ReMatIds[VNI->id] == VirtRegMap::MAX_STACK_SLOT) { 00988 // Each valnum may have its own remat id. 00989 ReMatIds[VNI->id] = vrm.assignVirtReMa...

> 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

...; Note that this doesn't clear the stack slot or remat mappings. > > In the particular code I'm looking at, linear scan spills an > interval and > one of the intervals created (%reg1631) gets mark as > rematerializable by > LiveIntervals: > > 00984 if (CreatedNewVReg) { > 00985 if (DefIsReMat) { > 00986 vrm.setVirtIsReMaterialized(NewVReg, ReMatDefMI/*, > CanDelete*/); > 00987 if (ReMatIds[VNI->id] == VirtRegMap::MAX_STACK_SLOT) { > 00988 // Each valnum may have its own remat id. > 00989 ReMatIds[...

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

...introduced by InlineSpiller::spillAroundUses which has determined that the register is live: // Rewrite instruction operands. bool hasLiveDef = false; for (const auto &OpPair : Ops) { MachineOperand &MO = OpPair.first->getOperand(OpPair.second); MO.setReg(NewVReg); if (MO.isUse()) { if (!OpPair.first->isRegTiedToDefOperand(OpPair.second)) MO.setIsKill(); } else { if (!MO.isDead()) hasLiveDef = true; } So I suppose we could either make LiveIntervals::computeDeadValues mark the individual defs...

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