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

Dear LLVMers OK, when I signed up for this mailing list, I asked for a once-daily digest. This is the fourth digest I receive today, and there are about that many each day. The only reason I subscribe to the mailing list is so I can post to it. But I don't need to receive the emails, because I can fully well read them in the archive online, and I certainly don't want to get spammed

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

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

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

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

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

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

Hi Arnaud, The conservatively allocatable test is supposed to check two conditions, either of which would be sufficient to make a node allocatable: (1) There exists some register that is not aliased by any register option for any neighbor. This is the "safe row" test. It is straightforward, but likely to fire only rarely. (2) The sum of the maximum number of registers aliased by any

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

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 Wed, Aug 26, 2009 at 11:58 AM, Dale Johannesen<dalej at apple.com> wrote: > > On Aug 26, 2009, at 11:54 AMPDT, Devang Patel wrote: > >> On Wed, Aug 26, 2009 at 10:59 AM, Dale Johannesen<dalej at apple.com> wrote: >>> >>> You may have noticed I added an "inlinehint" attribute to the IR >>> yesterday, to represent user declarations

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

- Re-sending to include llvm-dev. HI Jonas, This is great - thank you very much for your analysis! You're spot on about Bug 1 - the row/column checks are transposed there. I have fixed this in r227628. Regarding Bug 2, as discussed on the other thread I'm going to teach the register allocator to prune single-option vregs so that they never make it into the graph. I haven't had a

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,

On Mar 17, 2008, at 6:22 PM, Devang Patel wrote: > > On Mar 17, 2008, at 5:46 PM, Dale Johannesen wrote: > >> I'm getting a lot of these from TOT make: >> >> /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In >> instantiation of 'llvm::LoopInfoBase<llvm::BasicBlock>': >>

Adding "--enable-assertions" to the llvm-gcc configure line causes the build to fail. Having just LLVM configured with --enable- assertions doesn't reproduce the error. An assertion build (the Apple way) doesn't assert. -bw On Sep 19, 2007, at 5:48 PM, Dale Johannesen wrote: > This should have gotten an assertion failure in a compiler built > with assertions,

Devang, I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. Chad On Nov 14, 2011, at 4:39 PM, Devang Patel wrote: > I filed PR 11378. > Thanks! > - > Devang > > On Nov 14, 2011, at 1:27 PM, Galina Kistanova wrote: > >> Hello Devang, >> >> Please find attached the preprocessed source file and the LLVM >>

Hi, Sorry for the delay, it has taken some extra time as more than one bug showed up ☺ I continued to look into this with your viewpoint that a node that is conservatively allocatable should never be spilled. The first thing I did was therefore to add some extra code with an assert for this. I believe I then found three bugs and fixed the two: Bug 1: Incorrect transpositions in handleAddEdge()

Hi Dale, > 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. >