search for: spilling

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

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

> 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

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

.... On 2018-01-30 13:23, Matthias Braun wrote: > 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 correctly. >> >> If the accesses (writes and reads...

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

...of overlapping intervals and thus edges in the PBQP graph. It gets pushed on the node stack to later be popped after 17 others. Those 17 nodes use up all registers of the narrow reg-class, and the cost vector has become all infinities. Spill option is selected again, and thus the error is a fact of spilling an already spilled value. I wonder what has gone wrong here, and have some initial thoughts: * The problematic node that was spilled again, was in the ConservativelyAllocatableNodes set during reduce(). The comment in reduce() "Conservatively allocatable nodes will never spill..." indic...

...CPU2006 shows the performance difference of most tests to be in the noise (<1%). Depending on architecture (btver2 or Haswell), libquantum and mcf shows minor improvement. The only consistent slow-down (both btver2 and Haswell) is lbm, which shows a decrease of 1-2%. Here, I can see that not spilling rematerializable ranges produces an extra spill in the hot loop (5 rather than 4). However, the greedy register allocator allocates half the number of spill slots (5 rather than 10) but when splitting the spiller appears to be able to remove spills as redundant. Obviously much more work needs to b...

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,

...30 13:23, Matthias Braun wrote: >> 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 correctly. >>> &g...

...[40, 45) ) > and can be colored entirely by one register on the next iteration. Right. Live range splitting would indeed be nice to have. Bill's implementation has a flavor of it. > Unfortunately, it seems that current implementation doesn't support such > "clever" spilling. True. People have talked about adding it ever since I started getting involved. > Anyway, this precoloring doesn't force allocation algorithms to be > non-iterative. In my implementation of optimistic register coloring I > precolor spill intervals at the beginning of each iteratio...

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 correctly. > > If the accesses (writes and reads) to sub-registers are expressed always as sub-r...

...have to be the shortest when some interval is spilled the first time. But during iterations uncolored spill intervals should become shorter and shorter until they are must-be-precolored. > Unfortunately, it seems that current implementation doesn't support such > > "clever" spilling. > > True. People have talked about adding it ever since I started getting > involved. > > > Anyway, this precoloring doesn't force allocation algorithms to be > > non-iterative. In my implementation of optimistic register coloring I > > precolor spill intervals a...

...gt; > taken? Why can't the local spiller or the former rewriteFunction() > part > > of the RegAllocLinearScan find out on their own which of the > currently > > available for allocation physical registers should be taken at a > given > > point for a reload or for a spilling operation for a given spilled > live > > interval? Wouldn't it be more convenient? You just say that the > > interval is spilled and the rest is done "by magic"? Or may be I'm > > missing something about how spilling currently works in LLVM? > > > &gt...

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, > >>&g...

...can be used in loads/stores. Thanks, Ahmed On 2018-01-29 20:20, Matthias Braun wrote: >> On Jan 29, 2018, at 1:20 PM, ahmede via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> 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. > What would you have the register allocator do when it runs out of > register and you have spilling disabled? Abort the compilation? > > If you just want a special instr...

...e used in loads/stores. > > > Thanks, > Ahmed > > > On 2018-01-29 20:20, Matthias Braun wrote: >>> On Jan 29, 2018, at 1:20 PM, ahmede via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> 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. >> What would you have the register allocator do when it runs out of >> register and you have spilling disabled? Abort the compilation? >> If you just want a special instruction sequenc...

...which physical register should be > taken? Why can't the local spiller or the former rewriteFunction() part > of the RegAllocLinearScan find out on their own which of the currently > available for allocation physical registers should be taken at a given > point for a reload or for a spilling operation for a given spilled live > interval? Wouldn't it be more convenient? You just say that the > interval is spilled and the rest is done "by magic"? Or may be I'm > missing something about how spilling currently works in LLVM? > > Thanks in advance for any cl...

...id. > > AMDGPU does something a bit different IIRC, it basically runs the > allocator several times: > - First they allocate GPRs and spill them into SPR, since SPR registers > are not taken into account during this iteration there is no issue for > creating new live ranges during spilling for these ones > - Second they allocate SPRs and they get spilled to memory. > > Cheers, > -Quentin > > On Dec 17, 2019, at 1:47 PM, Hendrik Greving via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hello, for an architecture that doesn't have a good way t...

...sted by Bill W. some time ago has this code in it (the **** comments are my own): /// SpillLiveInterval - Assign a live interval to a stack slot. /// void RegAlloc::SpillLiveInterval(LiveInterval* LI) { [...] int Slot = VRM->assignVirt2StackSlot(LI->reg); DEBUG(std::cerr << "Spilling " << *LI << " into slot " << Slot << "\n"); std::vector<LiveInterval*> Added = LIs->addIntervalsForSpills(*LI, *VRM, Slot); static unsigned J = 0; for (unsigned I = 0; I < Added.size(); ++I, ++J) { unsigned VReg = Added[I]...