search for: spills

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

...wrote: > 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 case. > > Cheers, > -Quentin > >> On Jan 29, 2018, at 6:38 PM, ahmede via llvm-dev >> <llvm-dev at lists.llvm.org> w...

...ct register that is spilled. 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...

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

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

...1 value to the stack 113 instructions in foo Unfortunately, the performance showed only minimal improvement. *** Experiment Three The code gives no explanation for the spill weight adjustment value of 0.5. This experiment was designed to determine what adjustment factor was needed to obtain no spills. This point was reached with an adjustment factor for rematerializable intervals of 0.3. Modified: No spills to the stack 111 instructions in foo Again, the performance showed only minimal improvement. *** Experiment Four In the previous experiments splitting was still occurring leading to re...

..., 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) # spill to stack slot FXLV r10, 32(r3.0) SV r10, 32(r63.1) # spill to stack slot FXLV r10, 48(r3.0)...

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

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 which register we pick to color it.

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

...In Bill W's implementation, it was > essentially > random. What was your solution to this? I allocated spill intervals at the beginning of each iteration so all the rest intervals (except of physreg intervals) were uncolored at the moment. So the only difference in allocating regs for spills was what end to choose: allocation_order_begin() or allocation_order_end(), I chose the former. I understand that sometimes you can prefer one register over another for spill so it won't conflict with as much intervals as it would being mapped to another phys, but the same can be said about eve...

...I > believe that some live ranges may be split into bigger pieces, and > this would save some reloads. Seems so. Best, Roman > > When I look at the code, it seems that when linear scan > regalloc > > decides to spill a given live interval, it calls > addIntervalsForSpills. > > This function would split the original live interval into several > > intervals according to the principle described by you above. Each > of > > this intervals (split children) then gets a stack slot allocated > (and > > all these split intervals get the same stac...

...1, Evan Cheng wrote: > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > >>> Evan, > >>> > >>> Can you explain the basic mechanics of the live interval > splitting code? > >>> Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills > >>> and child routines? What is it trying to do? > >> > >> It's splitting live intervals that span multiple basic blocks. > That is, when an interval is spilled, it introduce a single reload per >>> basic block and retarget all the uses to use the re...

...sters 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 sequence (like using a bigger > loads/stores for the spills) then you should be able to implement that > in storeRegToStackSlot()/loadRegFromStackSlot(). > > - Matthias > >> >> 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 >>...

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 case. Cheers, -Quentin > On Jan 29, 2018, at 6:38 PM, ahmede via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Matthias, > > No. I want the reg...

...Also, in the new allocator used in LLVM, I believe that some live ranges may be split into bigger pieces, and this would save some reloads. best, Fernando > When I look at the code, it seems that when linear scan regalloc > decides to spill a given live interval, it calls addIntervalsForSpills. > This function would split the original live interval into several > intervals according to the principle described by you above. Each of > this intervals (split children) then gets a stack slot allocated (and > all these split intervals get the same stack slot?) and then those new &g...

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

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 to change virtual registers to physical registers (mapping given by the caller in the VRM, presumably the caller is regalloc). My question concerns duty #2. The...