search for: spill

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

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

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

Hi Quentin, Let me clarify if I understood this correctly. If the accesses (writes and reads) to sub-registers are expressed always as sub-registers of the super-register register class (e.g., SuperReg.sub1;), then the spilling decision is for the super register. But, if the accesses are in terms of the register class of the sub-registers directly (SubReg;), then the spilling decision will be for the sub-register. So if we forced before register allocation all sub-register accesses to be accessed to "lanes&q...

Right Matthias, I am aware that an implementation for storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these functions receive the physical register that need to be spilled, they might receive the sub-register. In this case, using the super-register naively is unsafe (e.g., one might overwrite parts of it). Thus, I think the register allocator/spillar need to be aware of the exact register that is spilled. On 2018-01-30 13:23, Matthias Braun wrote: > I sti...

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 spill close to its reloads. In the AArch64 code below, there is a spill(x2) in the e...

Hi, I have run into a test case on an out-of-tree target where PBQP fails to complete register allocation after "Attempting to spill already spilled value" (the triggered assert in InlineSpiller::spill(). First, the original LiveInterval is spilled. It is a load of a symbol into a narrow register class, i.e. a subset of the class of address registers. InlineSpiller decides to rematerialize the load of the symbol to lie rig...

...llowing: foo: ... vmovaps .LCPI0_0(%rip), %xmm8 # xmm8 = [6.366197e-01,6.366197e-01,...] ... vmulps %xmm8, %xmm0, %xmm1 # first use of constant vmovaps %xmm8, %xmm9 # move constant into another register ... vmovaps %xmm0, -40(%rsp) # 16-byte Spill vmovaps %xmm9, %xmm0 # move constant into vacated register ... vmulps %xmm0, %xmm3, %xmm2 # second use of constant ... vmulps %xmm0, %xmm5, %xmm3 # last use of constant ... The constant is used 3 times within a live range of 86 instructions. Although...

Hello, My target features some very-high-latency instructions that access an on-chip network (we'll call them FXLV). In one important kernel (snippet below), register allocation needs to spill values resulting from FXLV. The spiller is unaware of FXLV's latency, and thus naively inserts those spills immediately after the FXLV, incurring huge and unnecessary data stalls. FXLV r10, 0(r3.0) SV r10, 0(r63.1) # spill to stack slot FXLV r10, 16(r3.0) SV r10, 16(r63.1) #...

...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 register that need to be spilled, they > might receive the sub-register. In this case, using the super-register > naively is unsafe (e.g., one might overwrite parts of it). Thus, I > think the register allocator/spillar need to be aware of the exact > register that is spilled. > > > > On 2018-01-30 13:...

On Monday 06 August 2007 12:15, Anton Vayvod wrote: > Spill intervals must be precolored because they can't be spilled once more. > They are the shortest intervals precisely over each def/use of the original > interval. That is why they also have their weights set to #INF. Yes, that's true. But I wonder if we shouldn't be smarter about w...

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, > > Let me clarify if I understood this...

On 8/7/07, David Greene <dag at cray.com> wrote: > > On Monday 06 August 2007 12:15, Anton Vayvod wrote: > > > Spill intervals must be precolored because they can't be spilled once > more. > > They are the shortest intervals precisely over each def/use of the > original > > interval. That is why they also have their weights set to #INF. > > Yes, that's true. But I wonder if we sho...

Hi Fernando, --- Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to > having register to reload spilled values. Ok. That I can follow. > Once a register is spilled, its live range is split into smaller > pieces. These pieces most be contained into registers, and it is the > task of the allocator to find these registers. I'm not quite sure about the last statement. See below....

Hi Evan, I have a few questions about current implementation of live intervals spilling, which is required for the implementation of Extended Linear Scan algorithm. --- Evan Cheng <evan.cheng at apple.com> wrote: > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > >>> Evan, > >&gt...

Hi Matthias, No. I want the register allocator to spill the super-register (the large one e.g., 64-bit) and not just the sub-register (e.g., the 32-bit that is a piece of of the 64-bit register) because the stack loads/store width is 64-bit in this example. RegClass1 (sub-registers): sub_registers (32-bit) --> can be natively us...

Hi Ahmed, If you access your values with sub-registers indices, IIRC the inline spiller will spill the super register. If you access your values directly (via sub-regclass), then the spiller uses this class. Basically what I am saying is the spiller spills the value that contains the accesses. E.g., = v; will spill v = v.sub1; will spill v too, but v is a super register in that ca...

Hi, Roman, maybe I can try to answer this. I think that all boils down to having register to reload spilled values. Once a register is spilled, its live range is split into smaller pieces. These pieces most be contained into registers, and it is the task of the allocator to find these registers. Imagine that you have something like: Before After allocation: allocation: a := 1...

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 spill does not have any uses , e.g. see InlineSpiller.cpp, allDefsAreDead() calls. This made me wonder if this is supported natively at all. On Wed,...

Can someone explain the theory behind the spillers in VirtRegMap.cpp? It seems as though the spillers do triple duty: - Insert load/store operations and/or fold instructions as necessary to carry out spills - Rewrite the spilled virtual registers to use machine registers (mapping given by the caller in the VRM). - Rewrite machine code t...