search for: virtreg

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) 00186 return true; 00187 // Split register can be assigned a physical register as w...

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 (getStackSlot(virtReg) == NO_STACK_SLOT && > 00185 getReMatId(virtReg) == NO_STACK_SLOT) > 00186 return true; > 00187 // Split register can be assi...

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtR...

...ain later with the prototype code. On Thu, Dec 10, 2015 at 3:52 PM Derek Schuff <dschuff at google.com> wrote: > On Thu, Dec 10, 2015 at 2:46 PM Matthias Braun via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> To say this first: This whole discussion about using virtregs until emit >> or having growable physregs is hard to argue without actually having >> experience trying to go either way. >> > > Indeed, we are accumulating exactly this experience now, having started > with VRegs, as that seems like a more natural fit conceptually. The...

I'm having no luck getting my register allocator to work. I'm trying to do it using the "indirect" approach; i.e., using a VirtRegMap, with calls to assignVirt2Phys, assignVirt2StackSlot, etc. and a call to a "spiller" at the end. As a warm-up exercise (before implementing register allocation via graph coloring) I'm trying to implement a very simple scheme in which NO pseudo-registers are allocated to physic...

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 ((TargetRegisterInfo::isVirtualRegister(VirtReg)) && (VRM->getPhys(VirtReg) == REG_Y)) { LiveInterval &LI = LIS->getInterval(VirtReg); unassign(LI, REG_Y); enqueue(&LI); } } RegClassInfo.runOnMachineFunction(VRM->get...

...ded' defined but not used This has been introduced because of r46821. However, maybe removing just the variable isn't enought, because the comments in the section that got modified by 46821 are not optimal: if (PhysReg) { // Register is available, allocate it! assignVirtToPhysReg(VirtReg, PhysReg); } else { // No registers available. // If we can fold this spill into this instruction, do so now. This comment says that something should be folded. SmallVector<unsigned, 2> Ops; Ops.push_back(OpNum); I don't understand the usage of Ops. Seems not to b...

.... > > > On Thu, Dec 10, 2015 at 3:52 PM Derek Schuff <dschuff at google.com> wrote: > >> On Thu, Dec 10, 2015 at 2:46 PM Matthias Braun via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> To say this first: This whole discussion about using virtregs until emit >>> or having growable physregs is hard to argue without actually having >>> experience trying to go either way. >>> >> >> Indeed, we are accumulating exactly this experience now, having started >> with VRegs, as that seems like a more natura...

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is...

...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 ((TargetRegisterInfo::isVirtualRegister(VirtReg)) > && (VRM->getPhys(VirtReg) == REG_Y)) > { > LiveInterval &LI = LIS->getInterval(VirtReg); > unassign(LI, REG_Y); > enqueue(&LI); > } > } >...

...ith the fast register allocator. You will need some custom code in RAGreedy since the current target APIs don't support this. When you spill, you can evict live ranges assigned to your 'reserved' register and put them back on the work queue. See for example the RAGreedy::LRE_WillShrinkVirtReg() callback. You can choose to evict all live ranges assigned to that register and reserve it, or you can just evict the single live range crossing your spill code if you just need the register to be available for spilling. You can also use the PBQP register allocator which already supports multi-...

----- Original Message ----- > From: "Kevin B Smith" <kevin.b.smith at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>, llvm-dev at lists.llvm.org > Sent: Thursday, December 10, 2015 2:32:36 PM > Subject: RE: [llvm-dev] Allowing virtual registers after register allocation >

...to make it explicit if a target wants to use vregs after regalloc. > This way we can actually differentiate the cases where vregs appear after register allocation because of a bug and the case where they are intentional. The important thing would be to add something like MachineRegisterInfo::setVirtRegsAfterRegalloc() and MachineRegisterInfo::getVirtRegsAfterRegalloc(). Because I would assume that we will find more examples like the following (from MachineBasicBlock): > > void addLiveIn(MCPhysReg PhysReg, LaneBitmask LaneMask = ~0u) { > LiveIns.push_back(RegisterMaskPair(PhysReg,...

...hich already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. For the def-operand, with a subregindex, an implicit-use operand was added with this code: VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); MI.addOperand(MachineOperand::CreateReg(VirtReg, false, // isDef true)); // isImplicit As, can be seen, it is presumed that this operand is always the last operand, this is however not the case. It in fact becomes the first of the impl-use operands....

Yes, I want the register to be allocatable when there are no stack frames used in the function so it can be used for other purposes. In fact, I looked at how other backends solve this problem, but they are all too conservative by always reserving the register which in my case it is not a good solution because of the performance impact of not having this register available. I find very interesting

...me bug. Two questions: 1) At least, it would be better if LLVM would crash on an assertion instead of running for ever in such situations. I think this can be easily detected, since this is a case where nothing could be spilled. 2) You write in PR711: >This is due to the coallescer coallescing virtregs with both EAX and >EDX, which makes them unavailable to satisfy spills, causing the RA to >run out of registers. We want to coallesce physregs when possible, >but we cannot pin them in the spiller: >we have to be able to >uncoallesce them. First of all, I totally agree with &qu...

...hysregs, starting from 0. Each regunit corresponds to one or two physregs, the 'roots', which are typically leaf registers. The mapping is exposed by MCRegUnitIterator and MCRegUnitRootIterator. Regunit live intervals are more strictly defined than the old physreg intervals. The same way a virtreg interval can be computed from all machine operands mentioning the virtreg, regunit intervals can be computed from all physreg operands with TRI->hasRegUnit(MO.getReg(), RegUnit). However, while virtreg live intervals have a one-to-one mapping with machine operands, regunit intervals have a many...

Hi Jakob, I've got a good test case that I'm working on at the moment. I noticed something odd though: Is '0' a valid register unit? I'm seeing a LiveInterval with li->reg == 0 show up, which previously wasn't valid. We have a few checks around the place to disregard the '0' physreg - could these trigger on interaction with a '0' interval? That could

Hi Susan, Jakob just pointed me to 'MachineOperand::substPhysReg(unsigned preg, const TargetRegisterInfo& TRI)'. That substitutes the given physreg for a virtreg operand, taking the subregister index into account. That is what my examples have been doing manually. Using substPhysReg would allow you to tidy the Gcra code up slightly. - Lang. On Thu, Nov 15, 2012 at 11:21 AM, Lang Hames <lhames at gmail.com> wrote: > Thanks Jakob. I should have m...

...he function with MRI->addPhysRegsUsed(UsedInInstr); > and LR is callee saved correctly during prolog/epilog insertion. > > But with fast register allocator the following lines ignore the Def on > LR in the call instruction: (line 747) > > if (TID.isCall()) { > // Spill all virtregs before a call. This serves two purposes: 1. If an > // exception is thrown, the landing pad is going to expect to find registers > // in their spill slots, and 2. we don't have to wade through all the > // <imp-def> operands on the call instruction. > DefOpEnd = VirtOpEnd; &...