similar to: Problems with spill/reload and register scavenging

I have a question about register scavenger. I am considering using register scavenger for MIPS to free up register AT which is currently reserved to load large immediates. All targets which currently use register scavenger to search for a scratch register (ARM, CellSPU, PowerPC and XCore) override function processFunctionBeforeCalleeSavedScan and call RegisterScavenger::setScavengingFrameIndex

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 ran into another issue with register scavenger. In my case, I don't need a place on the stack for an emergency spill slot. I have these free mips32 registers, that are not in general very useful for other things, for the emergency spill slot. I can move to and from mips16 (subset of mips32) registers and mips32 registers. I also have a situation where I need two free registers so then

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

On Feb 28, 2010, at 11:49 PM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > Jakob Stoklund Olesen skrev: >> On Feb 26, 2010, at 10:09 AM, Scott Michel wrote: >>> This patch now causes new problems in the CellSPU >>> backend (more stqd's and lqd's), so I have to investigate those >>> before committing the patch. >

Hi, I would like to know what register scavenging is, but reading RegisterScavenging.h [1] and googling don't help too much. Could someone explain it a little bit (what it is and when we need it), or point me to some nice link, I will be very appreciated. :-) [1] http://llvm.org/docs/doxygen/html/RegisterScavenging_8h_source.html Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage:

> From: junbuml at codeaurora.org [mailto:junbuml at codeaurora.org] > Sent: Thursday, February 22, 2018 11:39 AM > > On 2018-02-22 11:14, gberry at codeaurora.org wrote: > > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > > Jun Lim via llvm-dev > > SENT: Thursday, February 22, 2018 11:05 AM > > > > Hi All, > > > > I

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Jun Lim via llvm-dev Sent: Thursday, February 22, 2018 11:05 AM Hi All, I found some cases where a spill of a live range in a block is reloaded only in one of its successors, and there is no reload in other paths through other successors. Since the spill is reloaded only in a certain path, it must be okay to sink such

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 2018-02-22 11:14, gberry at codeaurora.org wrote: > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > Jun Lim via llvm-dev > SENT: Thursday, February 22, 2018 11:05 AM > > Hi All, > > I found some cases where a spill of a live range in a block is > reloaded only in one of its successors, and there is no reload in > other paths through other

Hi All, I found some cases where a spill of a live range in a block is reloaded only in one of its successors, and there is no reload in other paths through other successors. Since the spill is reloaded only in a certain path, it must be okay to sink such spill close to its reloads. In the AArch64 code below, there is a spill(x2) in the entry, but this value is reloaded only in %bb.1, not in

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

That breaks the whole IR idea of using alloca to allocate/denote space for local variables, and then optimize those into SSA values when optimization proves that is OK. Also, for a lot of things, that attribute is simply impossible to implement. Any value that is live across a call needs to be spilled to memory. You cannot put an unspillable value in a callee preserved register, because you

s/llvm-commits/llvmdev/ On Dec 9, 2011, at 12:58 PM, Arnold Schwaighofer wrote: > >> As Jakob pointed out to me, the core problem is that the current >> register scavenger implementation will only give you one register; for >> the PowerPC case, and it looks like for your case as well, we might >> really need two registers. In the short term, a reasonable solution

You mean when I "explicity" use it by calling methods of register scavenger? Right now I'm just allocating virtual registers that will be resolved by the use of register scavenger and I'm also providing an override of the virtual method saveScavengerRegister. In Mips16, I have an extra mips 32 register (not usually very useful since it can only be used in a move instruction)

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

I'm debugging my iterated coalescing implementation and I've come across what I think is an inconsistency in spill code interval generation. The bug shows up when there's a copy that has its source register spilled. When the coalescer comes back around to try to coalesce the copy, the merge code complains that there are no values copied from the RHS. For example: Examining copy

Hello LLVMers! I recently added a generic machine rewriter/spiller that global register allocator writers may find useful. The API provided is the free function: void eliminateVirtRegs(MachineFunction&, const VirtRegMap&) declared in lib/CodeGen/VirtRegMap.h and implemented in lib/CodeGen/VirtRegMap.cpp. This function rewrites the machine code of MachineFunction to eliminate

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