llvm dev - Jan 2008 - [LLVMdev] LiveInterval Splitting & SubRegisters

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