Hi Jakob, I believe Hal is trying to enable register scavenger to find two (or more) registers that can be used as temporaries. One problem I see with this approach is that, if you use register scavenger during PEI, you will have to pessimistically set aside two emergency spill slots before you call scavengeRegister, even if it turns out you only need one. Having an extra stack slot might not be a big problem, but still it is nice if we can avoid allocating a slot unnecessarily. I probably won't need these pseudo instructions that are expanded post-RA in the first place if I can tell the register allocators to spill accumulator registers to general purpose integer registers instead of directly to stack and disallow copying between accumulator registers. But I guess that is a much more difficult problem to solve. Is that right? On Mon, Mar 25, 2013 at 1:06 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:> > On Mar 25, 2013, at 12:04 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > This patch adds parameter "EliminateFI" to > RegScavenger::scavengeRegister, which tells register scavenger not to > eliminate frame index of the emergency spill slot if set to false. > > > > I have pseudo load, store and copy instructions which are generated > during register allocation and expanded post-RA but before the final stack > size is known. I use register scavenger to search for a temporary integer > GPR that is used during pseudo-expansion. > > > > This is what happens during pseudo-expansion: > > > > The following pseudo > > > > LoadAC $acc, FI // Pseudo load instructions. Load from FI to accumulator > $acc. > > > > > > is expanded into this sequence: > > > > LW $reg, FI // load from FI to temporary GPR $reg > > MTLO $reg // copy $reg to register LO > > LW $reg, FI + 4 // load from FI+4 to GPR $reg > > MTHI $reg // copy $reg to register HI > > Hi Akira, > > The register scavenger is not really supposed to be used in more than one > pass, because you would need to allocate a separate emergency spill slot > for each pass. > > I think Hal is trying to solve a very similar problem for PPC. > > Hal, are you expanding pseudos during PEI? > > /jakob > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130325/14fc9f12/attachment.html>
Jakob Stoklund Olesen
2013-Mar-25 21:07 UTC
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
On Mar 25, 2013, at 1:41 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:> Hi Jakob, > > I believe Hal is trying to enable register scavenger to find two (or more) registers that can be used as temporaries. > > One problem I see with this approach is that, if you use register scavenger during PEI, you will have to pessimistically set aside two emergency spill slots before you call scavengeRegister, even if it turns out you only need one. Having an extra stack slot might not be a big problem, but still it is nice if we can avoid allocating a slot unnecessarily. > > I probably won't need these pseudo instructions that are expanded post-RA in the first place if I can tell the register allocators to spill accumulator registers to general purpose integer registers instead of directly to stack and disallow copying between accumulator registers. But I guess that is a much more difficult problem to solve. Is that right?That depends. The register allocator can spill across register classes, but it calls the functionality "live range splitting" and "register class inflation". Here's how you enable it: - Define a union register class that contains both CPU64Regs and ACRegs. - Implement TRI::getLargestLegalSuperClass(), and return the new union register class when asked about CPU64Regs or ACRegs (or their sub-classes). - Teach TII::copyPhysReg() to handle the cross-class copies. - Teach TII::storeRegToStackSlot() to constrain the register class to CPU64Regs when asked to spill a virtual register from the union register class. This will use cross-class spilling in most cases, but unfortunately we can't guarantee that an ACRegs virtual register will never be spilled. This just makes it much less likely to happen. Targets are still required to be able to spill all legal register classes. Instead of scavenging for registers during pseudo-expansion, I would like to make it possible to create new virtual registers during spilling. The plan is to give TII::storeRegToStackSlot() permission to: - Insert multiple instructions at the provided iterator, and - Create new virtual registers, possibly from different register classes. I think that functionality would solve your problems, right? The general idea is that the scavenger should only be used when it is not possible to determine at RA time if a register is needed. That would typically be because the frame layout is not known yet. If a register is always needed, RA should pick it. It is going to do better than the scavenger. Can you use Hal's scavenger tricks until we get this functionality added to the register allocators? (Help implementing it is always welcome, of course). /jakob
----- Original Message -----> From: "Akira Hatanaka" <ahatanak at gmail.com> > To: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Monday, March 25, 2013 3:41:21 PM > Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister > > Hi Jakob, > > I believe Hal is trying to enable register scavenger to find two (or > more) registers that can be used as temporaries. > > One problem I see with this approach is that, if you use register > scavenger during PEI, you will have to pessimistically set aside two > emergency spill slots before you call scavengeRegister, even if it > turns out you only need one. Having an extra stack slot might not be > a big problem, but still it is nice if we can avoid allocating a > slot unnecessarily.True; in general, this only affects us on PPC for functions with large stack frames, and even then only under the rare circumstance where we need to spill condition registers, so adding an extra stack slot does not seem like a big deal. Nevertheless, I view this as a temporary measure until Jakob's proposal to allow virtual registers to be created during spilling can be implemented. -Hal> > I probably won't need these pseudo instructions that are expanded > post-RA in the first place if I can tell the register allocators to > spill accumulator registers to general purpose integer registers > instead of directly to stack and disallow copying between > accumulator registers. But I guess that is a much more difficult > problem to solve. Is that right? > > > > On Mon, Mar 25, 2013 at 1:06 PM, Jakob Stoklund Olesen < > stoklund at 2pi.dk > wrote: > > > > > > On Mar 25, 2013, at 12:04 PM, Akira Hatanaka < ahatanak at gmail.com > > wrote: > > > This patch adds parameter "EliminateFI" to > > RegScavenger::scavengeRegister, which tells register scavenger not > > to eliminate frame index of the emergency spill slot if set to > > false. > > > > I have pseudo load, store and copy instructions which are generated > > during register allocation and expanded post-RA but before the > > final stack size is known. I use register scavenger to search for > > a temporary integer GPR that is used during pseudo-expansion. > > > > This is what happens during pseudo-expansion: > > > > The following pseudo > > > > LoadAC $acc, FI // Pseudo load instructions. Load from FI to > > accumulator $acc. > > > > > > is expanded into this sequence: > > > > LW $reg, FI // load from FI to temporary GPR $reg > > MTLO $reg // copy $reg to register LO > > LW $reg, FI + 4 // load from FI+4 to GPR $reg > > MTHI $reg // copy $reg to register HI > > Hi Akira, > > The register scavenger is not really supposed to be used in more than > one pass, because you would need to allocate a separate emergency > spill slot for each pass. > > I think Hal is trying to solve a very similar problem for PPC. > > Hal, are you expanding pseudos during PEI? > > /jakob > > >
On Mon, Mar 25, 2013 at 2:07 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:> > On Mar 25, 2013, at 1:41 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > Hi Jakob, > > > > I believe Hal is trying to enable register scavenger to find two (or > more) registers that can be used as temporaries. > > > > One problem I see with this approach is that, if you use register > scavenger during PEI, you will have to pessimistically set aside two > emergency spill slots before you call scavengeRegister, even if it turns > out you only need one. Having an extra stack slot might not be a big > problem, but still it is nice if we can avoid allocating a slot > unnecessarily. > > > > I probably won't need these pseudo instructions that are expanded > post-RA in the first place if I can tell the register allocators to spill > accumulator registers to general purpose integer registers instead of > directly to stack and disallow copying between accumulator registers. But I > guess that is a much more difficult problem to solve. Is that right? > > That depends. > > The register allocator can spill across register classes, but it calls the > functionality "live range splitting" and "register class inflation". Here's > how you enable it: > > - Define a union register class that contains both CPU64Regs and ACRegs. > > - Implement TRI::getLargestLegalSuperClass(), and return the new union > register class when asked about CPU64Regs or ACRegs (or their sub-classes). > > - Teach TII::copyPhysReg() to handle the cross-class copies. > > - Teach TII::storeRegToStackSlot() to constrain the register class to > CPU64Regs when asked to spill a virtual register from the union register > class. > > This will use cross-class spilling in most cases, but unfortunately we > can't guarantee that an ACRegs virtual register will never be spilled. This > just makes it much less likely to happen. > >I will look into this. It will probably alleviate the problem.> Targets are still required to be able to spill all legal register classes. > > > Instead of scavenging for registers during pseudo-expansion, I would like > to make it possible to create new virtual registers during spilling. The > plan is to give TII::storeRegToStackSlot() permission to: > > - Insert multiple instructions at the provided iterator, and > > - Create new virtual registers, possibly from different register classes. > > I think that functionality would solve your problems, right? > >Yes, it sounds like it will solve the problem. Using the following example where live ranges of accumulators $vreg_acc0 and $vreg_acc1 conflict, MULT $vreg_acc0, $vreg_gpr0, $vreg_gpr1 MULT $vreg_acc1, $vreg_gpr2, $vreg_gpr3 (consumer of $vreg_acc1) (consumer of $vreg_acc0) if the register can create new virtual registers $vreg_gpr4 and $vreg_gpr5, I think spilling can be avoided: MULT $vreg_acc0, $vreg_gpr0, $vreg_gpr1 copy $vreg_gpr4, $vreg_acc0:lo // spill lo copy $vreg_gpr5, $vreg_acc0:hi // spill hi MULT $vreg_acc1, $vreg_gpr2, $vreg_gpr3 (consumer of $vreg_acc1) copy $vreg_acc0:lo, $vreg_gpr4 // restore lo copy $vreg_acc0:hi, $vreg_gpr5 // restore hi (consumer of $vreg_acc0) Also, should RA avoid splitting live intervals of accumulators, which creates copy instructions? The general idea is that the scavenger should only be used when it is not> possible to determine at RA time if a register is needed. That would > typically be because the frame layout is not known yet. If a register is > always needed, RA should pick it. It is going to do better than the > scavenger. > > > Can you use Hal's scavenger tricks until we get this functionality added > to the register allocators? (Help implementing it is always welcome, of > course). > > Yes, I think I can, but I have to understand details of Hal's patch first.> /jakob > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130325/1c250951/attachment.html>