search for: virtregs

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

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

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

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

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)

lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' 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

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

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 a case where

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

On Nov 29, 2011, at 10:24 AM, Borja Ferrer wrote: > 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

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

Hi, I think I've found a bug in this method. I ran it on an MI which 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,

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

On Sep 10, 2012, at 2:26 AM, Lang Hames <lhames at gmail.com> wrote: > 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

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

...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; &g...