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 interval for a virtual register in the case
where a subregister extract was coalesced.
That information appears to now be in RegSubIdxMap, which is local to
runOnMachineFunction, so it's lost after the coalescer runs. Do I not need
to worry about this information anymore?
Thanks.
-Dave
On Tuesday 22 January 2008 14:23, 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?I should clarify. I understand what live range splitting is. What I'm asking here is exacly what this particular implementation targets: only live ranges across loops? Other stuff? You mentioned some time ago that the splitting implementation would be simplistic. I'm trying to get a handle on how simplistic it is. Maybe a better question is, what's _not_ handled/split? -Dave
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) split intra-bb intervals.> > 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 interval for a virtual register in > the case > where a subregister extract was coalesced.Right. That has been removed because it's surprisingly painful to maintain that information. Now subreg index lives on MachineOperand.> > That information appears to now be in RegSubIdxMap, which is local to > runOnMachineFunction, so it's lost after the coalescer runs. Do I > not need > to worry about this information anymore?That's used at the end of coalescing to rewrite virtual registers. It's purely local information. Evan> > Thanks. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wednesday 23 January 2008 02:01, Evan Cheng wrote:> > Can you explain the basic mechanics of the live interval splitting > > code?> 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) split intra-bb intervals.Ah, got it. Thanks.> > 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 interval for a virtual register in > > the case > > where a subregister extract was coalesced. > > Right. That has been removed because it's surprisingly painful to > maintain that information. Now subreg index lives on MachineOperand.Yep, I saw that. Does the subregh index in the MachineOperand tell the asm printer what name to output for a register operand? How else is it used?> > That information appears to now be in RegSubIdxMap, which is local to > > runOnMachineFunction, so it's lost after the coalescer runs. Do I > > not need > > to worry about this information anymore? > > That's used at the end of coalescing to rewrite virtual registers. > It's purely local information.Ok, I see where that is happening (the coalescer sets the subreg in the MachineOperand). I'm worried here about the case where an EXTRACT_SUBREG targeting two virtual registers is coalesced. How does the LiveInterval information change? Since the coalescer always coalesces to the superregister, I'm guesing that LiveIntervals will have an (extended) interval for the superregister and NO interval foir the subregister after coalescing is done (since the subregister was coalesced away). Then when the AsmPrinter comes along, it sees the subregister set in the MachineOperand and does the Right Thing(tm) even though the MachineOperand register is in fact the superregister. Correct? Any other stuff happening besides this? Thanks for your help! -Dave
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 > reload. It does not (yet) split intra-bb intervals.How is this different from the way the spiller used to work, looking for reloads it could reuse? Didn't that have the same goal of not reloading a spilled value multiple times in a basic block? -Dave