similar to: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47

Here's issue 48. I'm guessing I'm going to get issue 49 as soon as I hit send... On Fri, Feb 15, 2008 at 3:28 PM, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > or, via

On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > >> >> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >> >>> >>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>> >>>>>> Alternatively I can take the Padding bit into account in the >>>>>>

Hi Evan, I have a few questions about current implementation of live intervals spilling, which is required for the implementation of Extended Linear Scan algorithm. --- Evan Cheng <evan.cheng at apple.com> wrote: > > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: > >>> Evan, > >>> >

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

On Jan 23, 2008, at 2:40 PM, David Greene <dag at cray.com> wrote: > 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

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

On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > >> >> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >> >>>>> Alternatively I can take the Padding bit into account in the >>>>> StructType::get code somehow. Anyone have a strong opinion? >>>> >>>>

Hi, Roman, maybe I can try to answer this. I think that all boils down to having register to reload spilled values. Once a register is spilled, its live range is split into smaller pieces. These pieces most be contained into registers, and it is the task of the allocator to find these registers. Imagine that you have something like: Before After allocation: allocation: a

On Feb 15, 2008, at 11:22 AM, Dale Johannesen wrote: > > On Feb 15, 2008, at 11:17 AM, Devang Patel wrote: > >> >> On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: >> >>> >>> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: >>> >>>> >>>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >>>>

Hi Fernando, --- Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to > having register to reload spilled values. Ok. That I can follow. > Once a register is spilled, its live range is split into smaller > pieces. These pieces most be contained into registers, and

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

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

Here's a cute bug in llvm-gcc's struct translation: struct S242 { char * a;int b[1]; } ; struct S93 { __attribute__((aligned (8))) void * a; } ; The second example is padded out to 8 bytes, so both of these look like { i8 *, [1 x i32] } This leads the "struct type factory" StructType::get to think they are the same. But, the second field is marked as Padding in the second

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

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

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

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 Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >>>> Alternatively I can take the Padding bit into account in the >>>> StructType::get code somehow. Anyone have a strong opinion? >>> >>> Shouldn't it be a map from the gcc type to the padding info? >>> That said, you can get

On 8/7/07, David Greene <dag at cray.com> wrote: > > 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,

> A node should never be put into the conservatively allocatable list if there is a chance of it spilling. I can understand why the logic of NodeMetadata::isConservativelyAllocatable is necessary for the node to be allocatable, but I have not been able to convince myself this is sufficient, especially when the node degree > available registers. Cheers, Arnaud From: