search for: addintervalsforspills

Hi, It looks like LiveIntervals::addIntervalsForSpills does not update all of the LiveIntervals infos quite correctly. In particular, if a live interval L is defined by Reg<-Reg copy instructions whose srcReg is later spilled by the addIntervalsForSpills() function, its VNInfo information is not updated in a proper way. It still points to the same...

On Wednesday 23 January 2008 02:01, 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 result of the single >...

Hello, I am currently working another register allocator for LLVM, and I have a few questions. I have a list of LiveIntervals that interfere with each other, and once I figure out that I need to spill one of these, I'm using LiveIntervals::addIntervalsForSpills to generate spill code. I'm not sure I'm using this function correctly (or if it's even the right thing to use). Here are a few questions: - What exactly is the SpillIs parameter for this function? - The return value is a vector of LiveIntervals, but it looks like they have all bee...

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? Also, in the ancient subregister coalescing code, there used to be an update of the SSARegMap to point subregisters to the superregister they were coalesced to (IIRC). That has since gone away. I used to use that in my code to return the correct live...

...l to be uncolorable? I don't think that's true. > Therefore, precoloring most certainly can cause harm because a decision > is being made in local context without the global information that could > help make a better one. At least this is the imply of LiveIntervals: try to call addIntervalsForSpills on a spill interval and you'll have an assertion (that was true at least for 1.9, probably it's true now). If spill interval has a length of 1 (and it has because of addIntervalsForSpills implementation) it can't be spilled again physically. Moreover if you were able to spill such inter...

...n Wednesday 23 January 2008 02:01, 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 resu...

...2 at 1074-(1095) Notice how the end of the second value for %reg1297 is the same as the start of %reg1057's first value. For every copy like there it's always the case that the source live interval's value "end" is the def slot for the instruction. In LiveIntervalAnalysis::addIntervalsForSpills, we have this: if (HasUse) { LiveRange LR(getLoadIndex(index), getUseIndex(index), nI.getNextValue(~0U, 0, VNInfoAllocator)); DOUT << " +" << LR; nI.addRange(LR); } Should this actually extend f...

...nuary 2008 02:01, 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...

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.

On Oct 5, 2007, at 5:52 PM, David Greene wrote: > > In LiveIntervalAnalysis::addIntervalsForSpills, we have this: > > if (HasUse) { > LiveRange LR(getLoadIndex(index), getUseIndex(index), > nI.getNextValue(~0U, 0, VNInfoAllocator)); > DOUT << " +" << LR; > nI.addRange(LR); >...

...he "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? RALinearScan asks the Spiller to spill a virtual register. The StandardSpiller passes the request to LiveIntervals::addIntervalsForSpills. Here, the spill and restore points are added to the VirtRegMap. No spill code has been inserted yet. After register allocation completes, VirtRegRewriter inserts the store and load instructions specified in VirtRegMap. The counters you are looking for are in VirtRegRewriter.cpp. We are working...

...iveInterval for each live range. But this will probably have a negative impact on performance and also reduce coalescing possibilities. c) May be LiveIntervals could be split after register allocation, just before rewriting? How this could be easily done? May be PreAllocSplitting or LiveIntervals::addIntervalsForSpills could be used for this purpose by slightly changing them? Interesting point here is that such splits can occur only at the MBB borders, since each live-ranges may get its own, but only one physical register May be there are also some other alternatives? At the moment, I cannot easily decide which...

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

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 result of the single reload. It does not (yet)...

...ce and also reduce coalescing > possibilities. Not to mention it will significantly increase memory usage. > > > c) May be LiveIntervals could be split after register allocation, just > before rewriting? How this could be easily done? May be > PreAllocSplitting or LiveIntervals::addIntervalsForSpills could be > used for this purpose by slightly changing them? Interesting point > here is that such splits can occur only at the MBB borders, since each > live-ranges may get its own, but only one physical register Well, are you sure it's a register per live-range? It's possible to...

...ways the case. 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...

...ng >> possibilities. > > Not to mention it will significantly increase memory usage. Yes, true. >> c) May be LiveIntervals could be split after register allocation, just >> before rewriting? How this could be easily done? May be >> PreAllocSplitting or LiveIntervals::addIntervalsForSpills could be >> used for this purpose by slightly changing them? Interesting point >> here is that such splits can occur only at the MBB borders, since each >> live-ranges may get its own, but only one physical register > > Well, are you sure it's a register per live-range?...

...rote: > > >> 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 retar...

...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]->reg; const TargetRegisterClass* RC = MF->getSSARegMap()->getRegClass(VReg); TargetRegisterClass::const_iterator Iter = RC->allocation_order_begin(*...

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