similar to: [LLVMdev] Spilling predicate registers

> I am not sure extending the scavenger is the right way to go about this. > > There are two different situations where we might need extra registers to > spill something: > > 1. When spilling a weird register class like predicate registers, we > already known during register allocation that we will need a scratch GPR > to assist with the spill. > > 2. When spilling

Hi Reed, the register scavenger (RS) also keeps track of live registers. This way it "knows" that the register that was spilled/restored far apart is available. Let say you had the following code. You need to find a register to keep vreg1 and vreg2 in. R1 = .... // <- RS current liveness state; we have called RS->forward(It) where It points to here vreg1 = add SP, 1000 ... =

I'm confused as to the logic used in the register scavenger when it cannot find a free register. I would think that it would want to free up the emergency spill slot immediately after it's use, because otherwise there is a chance of needing to use the emergency slot again and not be able to. Instead it tries to restore it only right before register it is freeing up. Maybe I'm

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

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

Hello all, For my custom processor backend I am trying add some instruction using BuildMI() inside eliminateFrameIndex(). I tried RegScavenger like this: unsigned RegUnused0 = RS->FindUnusedReg(&LASER::GNPRegsRegClass); if (!RegUnused0) RegUnused0 = RS->scavengeRegister(&LASER::GNPRegsRegClass, II, SPAdj); assert(RegUnused0 && "Register scavenger failed");

I'm having trouble with virtual registers/register allocation in my back-end. Basically the FastRegAlloc pass is generating calls to storeToStackSlot and loadFromStackSlot, in which we build new machine instructions, which are then _not_ processed by the reg allocator. I understand that BuildMI is changing the list of MachInst. that the allocator is iterating over, but we need to have a new

On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > other physical register which may be holding a live value used > somewhere else. How do I make regalloc aware so that it saves the > value before storeRegToStackSlot and make it available again at the > point of earlier use? >

On Thu, 2008-10-23 at 11:17 -0700, Evan Cheng wrote: > > On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > > > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > > other physical register which may be holding a live value used > > somewhere else. How do I make regalloc aware so that it saves the > > value before

Hello, for an architecture that doesn't have a good way to load/store a given register class to memory, is it instead easy to spill/fill from another register class instead? e.g. - storeRegToStack/loadRegFromStack use a pseudo instruction and add virtual register operand is not supported (spill optimization doesn't seem to like this). - AMDGPU backend seems to do sth. similar? The only

Thanks Jon and Hal for the helpful pointers. By returning true from requiresRegisterScavenging() and requiresFrameIndexScavenging(), LLVM handled all the scavenging effort. That is nearly painless for the target, so why do some targets seem to do scavenging on their own? When the scavenged register is loaded with a simple immediate, is it safe to search the BB and replace other uses of the same

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

On Sep 3, 2013, at 17:21 , Manuel Jacob <me at manueljacob.de> wrote: > The problem is to safe registers that contain gc pointers to the stack > before a call and reload them after the call. Is there an Analysis Pass > that computes information about which registers are live during a > specific instruction? I looked at LiveIntervals and LiveVariables, but > they seem to be for

Hi, I'm trying to implement my ideas about better garbage collection support [1]. The hardest problem seems to be to find all registers that are live at safe points (for example, during a call) and spilling them. Since nobody responded on the original thread, I decided to start a new thread specifically for this question. The problem is to safe registers that contain gc pointers to the stack

Ok, thanks. Except the question was meant slightly different. Less w.r.t. organizing the register classes, and more w.r.t. implementation. I've noticed for instance that when trying to model this straight forwardly by writing a vreg from spills and reading this from fills (not further elaborated here), that the spiller can't handle vreg def-use pairs: there are assertions making sure a

In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some other physical register which may be holding a live value used somewhere else. How do I make regalloc aware so that it saves the value before storeRegToStackSlot and make it available again at the point of earlier use? TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

I still think my answer applies that you have to modify storeRegToStackSlot()/loadRegFromStackSlot(). They decide how registers are spilled and reloaded. Nobody is stopping you from using super registers spills/reloads to implement spilling/reloading smaller registers there. - Matthias > On Jan 30, 2018, at 10:21 AM, ahmede <ahmede at ece.ubc.ca> wrote: > > Hi Quentin, > >

Hi, I wonder if there is a way in LLVM to disable spilling a register-class while still enabling the super-registers of this register-class to be spilled. If not, how can we implement spilling for sub-registers when stack load/stores can only operate on the super registers? Is there a way even if it is suboptimal? Thanks, Ahmed

To make my point clear, I believe an implementation of storeRegToStackSlot()/loadRegFromStackSlot() is not sufficient (as it received the physical register already). Does this make sense? On 2018-01-30 13:33, ahmede wrote: > Right Matthias, I am aware that an implementation for > storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these > functions receive the physical