search for: assignvirt2phys

...; Indeed there is a case where PhysReg may be a reserved physical register. Specificially, RegAllocPBQP::finalizeAlloc() may select a physical register thusly: const TargetRegisterClass &RC = *MRI.getRegClass(LI.reg); PReg = RC.getRawAllocationOrder(MF).front(); ... VRM.assignVirt2Phys(LI.reg, PReg); The documentation for TargetRegisterClass::getRawAllocationOrder() notes that the collection may include reserved registers. So it seems that the PBQP allocator may insert a reserve physical register into the VirtRegMap. I'm not sure which component should be fixed. Is it f...

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 physical registers across instructions....

...getReMatId(virtReg) == NO_STACK_SLOT) 00186 return true; 00187 // Split register can be assigned a physical register as well as a 00188 // stack slot or remat id. 00189 return (Virt2SplitMap[virtReg] && Virt2PhysMap[virtReg] != NO_PHYS_REG); 00190 } VRM::assignVirt2Phys is implemented as: 00147 void assignVirt2Phys(unsigned virtReg, unsigned physReg) { 00148 assert(TargetRegisterInfo::isVirtualRegister(virtReg) && 00149 TargetRegisterInfo::isPhysicalRegister(physReg)); 00150 assert(Virt2PhysMap[virtReg] == NO_PHYS_REG &&am...

Hi again Lang, I decided to try the approach you proposed to see whether it makes the assembly-code problem go away. Again, I tried a very simple register allocator (attached) that just calls vrm.assignVirt2Phys for every vreg in each function, mapping the vreg to the first preg in the register class. I tried two versions: one maps *every* vreg, and the other only maps those for which MRI->reg_empty(vreg) returns false. In both cases I get a core dump somewhere after my reg-allocation pass has run...

...} This is poorly named. All vr's will be assigned a physical register even if they are spilled or remat'd. This really should be isNotSpilledOrReMated. But then the exception is split register. Yeah, I know this is a mess. We are planning a complete rewrite. > > > VRM::assignVirt2Phys is implemented as: > > 00147 void assignVirt2Phys(unsigned virtReg, unsigned physReg) { > 00148 assert(TargetRegisterInfo::isVirtualRegister(virtReg) && > 00149 TargetRegisterInfo::isPhysicalRegister(physReg)); > 00150 assert(Virt2PhysMap[virtReg]...

...Nov 1, 2012 at 2:41 PM, Susan Horwitz <horwitz at cs.wisc.edu> wrote: > Hi again Lang, > > I decided to try the approach you proposed to see whether it makes the > assembly-code problem go away. Again, I tried a very simple register > allocator (attached) that just calls vrm.assignVirt2Phys for every vreg in > each function, mapping the vreg to the first preg in the register class. I > tried two versions: one maps *every* vreg, and the other only maps those > for which MRI->reg_empty(vreg) returns false. In both cases I get a core > dump somewhere after my reg-allocat...

...egisters directly through MachineRegisterInfo. Have your allocator require and preserve the VirtRegMap pass, then in your runOnMachineFunction pass grab a reference to the pass with: VirtRegMap &vrm = getAnalysis<VirtRegMap>(); You can then describe your register allocations with: vrm.assignVirt2Phys(<virtreg>, <physreg>) The VirtRegRewriter pass (in VirtRegMap.cpp) will run after your allocator and apply the mapping that you described in the VirtRegMap. I hope this helps. Let me know if it doesn't fix your issue. Cheers, Lang. On Wed, Oct 31, 2012 at 3:54 PM, Susan Horwitz...

...du > <mailto:horwitz at cs.wisc.edu>> wrote: > > Hi again Lang, > > I decided to try the approach you proposed to see whether it makes > the assembly-code problem go away. Again, I tried a very simple > register allocator (attached) that just calls vrm.assignVirt2Phys > for every vreg in each function, mapping the vreg to the first preg > in the register class. I tried two versions: one maps *every* vreg, > and the other only maps those for which MRI->reg_empty(vreg) returns > false. In both cases I get a core dump somewhere afte...

Thanks Lang! Here's another question: I'm trying to process this input: int main() { return 0; } but I'm getting an error Assertion `!Fn.getRegInfo().getNumVirtRegs() && "Regalloc must assign all vregs"' failed. At the start of runOnMachineFunction I call Fn.getRegInfo().getNumVirtRegs(); and find that there is 1 virtual register. However,

...tz at cs.wisc.edu>> wrote: >> >> Hi again Lang, >> >> I decided to try the approach you proposed to see whether it makes >> the assembly-code problem go away. Again, I tried a very simple >> register allocator (attached) that just calls vrm.assignVirt2Phys >> for every vreg in each function, mapping the vreg to the first preg >> in the register class. I tried two versions: one maps *every* vreg, >> and the other only maps those for which MRI->reg_empty(vreg) returns >> false. In both cases I get a core dum...

...Hi again Lang, > > I decided to try the approach you proposed to see whether > it makes > the assembly-code problem go away. Again, I tried a very > simple > register allocator (attached) that just calls > vrm.assignVirt2Phys > for every vreg in each function, mapping the vreg to the > first preg > in the register class. I tried two versions: one maps > *every* vreg, > and the other only maps those for which > MRI->reg_empty(vreg) returns...

...necessary for doing the reloading. Yes. But as you show above, it may happen that the same spilled virtual interval is reloaded into _multiple different_ physical registers during its lifetime. So, what is the reason to assign only one (!) physical register to the virtual interval by means of VRM.assignVirt2Phys() and to do it actually in advance? What is the semantics of it? I'd really like to understand it better. How does this solve the problem described above? Wouldn't it be better if the spiller or code rewriter (that replaces virtual regs with the corresponding allocated physical regs) would...

Hi Susan, > But this doesn't seem to be happening; the stores to memory are there but > the loads are not. > > Any ideas what's going wrong? Are you using VirtRegMap::addSpillPoint and VirtRegMap::addRestorePoint ? If not you may need to add calls to them to let the rewriter know where to insert the loads/stores. > If not, any advice on how to generate the loads

I found the problem! My generated code is spilling correctly but is not reloading at all. For example, if the original code has the equivalent of this (where %1024 is a virtual reg): %1024 = xxx ... yyy = %1024 and I find no physical register for %1024, then I assign it to physical register %edi and to a stackslot. That creates code like this: %edi = xxx store from %edi to the

...; wrote: >>> >>> Hi again Lang, >>> >>> I decided to try the approach you proposed to see whether it makes >>> the assembly-code problem go away. Again, I tried a very simple >>> register allocator (attached) that just calls vrm.assignVirt2Phys >>> for every vreg in each function, mapping the vreg to the first preg >>> in the register class. I tried two versions: one maps *every* vreg, >>> and the other only maps those for which MRI->reg_empty(vreg) returns >>> false. In both cases...

...I decided to try the approach you proposed to see >> whether it makes >> the assembly-code problem go away. Again, I tried a >> very simple >> register allocator (attached) that just calls >> vrm.assignVirt2Phys >> for every vreg in each function, mapping the vreg to >> the first preg >> in the register class. I tried two versions: one >> maps *every* vreg, >> and the other only maps those for which >&...

...; >>>> Hi again Lang, >>>> >>>> I decided to try the approach you proposed to see whether it makes >>>> the assembly-code problem go away. Again, I tried a very simple >>>> register allocator (attached) that just calls vrm.assignVirt2Phys >>>> for every vreg in each function, mapping the vreg to the first preg >>>> in the register class. I tried two versions: one maps *every* vreg, >>>> and the other only maps those for which MRI->reg_empty(vreg) returns >>>> false....

...RegMap()->getRegClass(VReg); TargetRegisterClass::const_iterator Iter = RC->allocation_order_begin(*MF); if (Iter + J >= RC->allocation_order_end(*MF)) J = 0; unsigned PReg = *(Iter + J); // **** Assign the newly-created live interval to a physical register VRM->assignVirt2Phys(VReg, PReg); PRT->addRegUse(PReg); DEBUG(std::cerr << "\tAdded LI: " << *Added[I] << " assigned Reg " << MRI->getName(PReg) << "\n"); for (LiveIntervals::const_iterator...

...roposed to see >>> whether it makes >>> the assembly-code problem go away. Again, I >>> tried a very simple >>> register allocator (attached) that just calls >>> vrm.assignVirt2Phys >>> for every vreg in each function, mapping the vreg >>> to the first preg >>> in the register class. I tried two versions: one >>> maps *every* vreg, >>> and t...

...gt;>> whether it makes >>>> the assembly-code problem go away. Again, I >>>> tried a very simple >>>> register allocator (attached) that just calls >>>> vrm.assignVirt2Phys >>>> for every vreg in each function, mapping the vreg >>>> to the first preg >>>> in the register class. I tried two versions: one >>>> maps *every* vreg, >>>>...