search for: spillers

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

Hi, Sorry for the delay. I was trying to wrap my head around some live interval analysis code and have forgotten about emails. :-) On Aug 6, 2007, at 9:20 AM, David Greene wrote: > 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 Actually folding decision was made during allocation. When the allocator decides to spill, it asks live in...

...In my implementation of optimistic register coloring I > precolor spill intervals at the beginning of each iteration and thus don't > have to spill their neghbours specifically. It was done automatically by > Select phase of algorithm. So how did you get around the requirement of the spillers that intervals be mapped to physical registers? Or did you not use the provided spillers? That may be what I end up doing. Loads and stores don't absolutely have to be inserted into the actual instruction text on each iteration, though it is nice for debugging purposes. > As Fernando has...

Hi, Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the spiller's class? Thanks, -- Silvio Ricardo Cordeiro --------------

Spiller::Spill( LiveInterval *li, SmallVectorImpl<LiveInterval*> &newIntervals, const SmallVectorImpl<LiveInterval*> &spillIs ); has two reference vectors which contain a small list of Live Intervals. What is the register allocator's job to do with these intervals other than analysis. What more needed other than to know

On Mon, 6 Aug 2007, David Greene wrote: >> split into smth like [10, 40) and [40, 50). The former part should not be >> precolored as it has less conflicts (it doesn't intersects with [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

Jeff Kunkel <jdkunk3 at gmail.com> writes: > Spiller::Spill( LiveInterval *li, >                           SmallVectorImpl<LiveInterval*> &newIntervals, >                           const SmallVectorImpl<LiveInterval*> &spillIs ); > > has two reference vectors which contain a small list of Live > Intervals. What is the register allocator's job to do

Hi, David. 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. Imagine that on a second iteration allocation algorithm figures out that some spilled interval can't be assigned a physical register. Allocator can't spill it

On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the

...mistic register coloring I > > precolor spill intervals at the beginning of each iteration and thus > don't > > have to spill their neghbours specifically. It was done automatically by > > Select phase of algorithm. > > So how did you get around the requirement of the spillers that intervals > be mapped to physical registers? Or did you not use the provided > spillers? > That may be what I end up doing. Loads and stores don't absolutely have > to be > inserted into the actual instruction text on each iteration, though it is > nice > for debuggi...

Hi all, I am working on an out-of-tree target. I am wondering if it is possible to force the register allocator (and/or spiller) to not break certain instruction sequence. For example: phys_reg = MI1 vreg1 vreg 2 = MI2 phys_reg Is there a way to tell RA/spiller not to insert COPY or spill between MI1 and MI2? I am using greedy register allocator and inline spiller. -- Regards, Dongrui

Hi guys, I have been using a debugger for my register allocator. The debugger happened to be very useful at catching register assignment errors. I've put the debugger on-line, if anyone who is working with register allocation wants to use. The debugger itself has nothing to do with LLVM, but I've coded a spiller that prints the code in a format that the debugger can read. The

On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of > loads/stores added by the "linearscan" register allocator (just like can be > done with the "local" allocator)? I still haven't

I thought about a little bit more, I think adding Register pressure control in your patch or PRE may be the only choice. Because at least for this case I am looking at, what your patch did is created more relatively complex long live range, rematerialization is not smart enough to undo your change or at least without a lot of work, coalescing only create even longer live range not shorter,

On Wed, Jul 15, 2015 at 1:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > IMHO, This doesn't make a lot of sense to turn off this part on it's own. > I would just use the enable-pre flag to turn off scalar PRE, as it > will cause the same issue in other cases as well. > Is there some reason you aren't just doing that? > I suspect if this is a performance

That should be literally impossible, which makes me think something was tested wrong The second patch i posted disables scalar pre (assuming you use -disable-pre) but not load pre. Since the patch you reverted touched only scalar pre, disabling scalar pre should *also* do the same thing. On Thu, Jul 16, 2015 at 5:43 PM, Lawrence <lawrence at codeaurora.org> wrote: > Hi, Daniel: >

Seems to be a bit of new warnings recently: llvm/llvm/lib/CodeGen/Spiller.cpp: In function 'void UpdateKills(llvm::MachineInstr&, llvm::BitVector&, std::vector<llvm::MachineOperand*, std::allocator<llvm::MachineOperand*> >&, const llvm::TargetRegisterInfo*)': llvm/llvm/lib/CodeGen/Spiller.cpp:221: warning: unused variable 'TID'

> > FYI, in my implementation I just marked the intervals introduced by > spills as being special so that they would not be chosen to be spilled > again. Then they just get colored like every other interval. But they can be uncolored like every other interval then, right? When your algorithm finds out during one iteration that it should spill some interval it checks whether this

On Aug 17, 2007, at 4:17 PM, Fernando Magno Quintao Pereira wrote: > > Hi guys, > > I have been using a debugger for my register allocator. The > debugger > happened to be very useful at catching register assignment errors. > I've > put the debugger on-line, if anyone who is working with register > allocation wants to use. The debugger itself has nothing to

I'm not sure about one thing: you assign stack slot to each new register you replace the spilled one with. And then you need to allocate physical registers to them. Is it possible to assign physical register to the virtual one which has a stack slot already? On 8/21/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > > So what addIntervalsToSpills