[LLVMdev] LLVMdev Digest, Vol 44, Issue 47

[Sebastien Loisel]

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 multiple times
daily with the digest. Today, I received issue 44 at 3:01am, issue 45 at
12:37pm, issue 46 at 2:02pm and issue 47 at 3:21pm.

Is there a way that I can turn off all delivery of emails from the llvmdev
list without unsubscribing? If that's not possible, I'll unsubscribe and
then resubscribe when I have something to say, but I just think it would be
better if I could turn off the email delivery or something.

Sincerely,

Sébastien Loisel

On Fri, Feb 15, 2008 at 3:21 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 email, send a message with subject or body 'help' to
>        llvmdev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
>        llvmdev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LLVMdev digest..."
>
>
> Today's Topics:
>
>   1. Re: an llvm-gcc bug (Devang Patel)
>   2. Re: an llvm-gcc bug (Chris Lattner)
>   3. Re: an llvm-gcc bug (Dale Johannesen)
>   4. Re: an llvm-gcc bug (Dale Johannesen)
>   5. Re: an llvm-gcc bug (Chris Lattner)
>   6. Re: Question on link error (Ted Neward)
>   7. LiveInterval spilling (was LiveInterval Splitting &
>      SubRegisters) (Roman Levenstein)
>   8. Re: LiveInterval spilling (was LiveInterval Splitting &
>      SubRegisters) (Fernando Magno Quintao Pereira)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 15 Feb 2008 11:17:33 -0800
> From: Devang Patel <dpatel at apple.com>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <0C222846-383D-41DD-8229-4858BD1FD3A2 at apple.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> 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?
> >>>>
> >>>> Shouldn't it be a map from the gcc type to the padding info?
> >>>> That said, you can get rid of the padding info as far as I'm
> >>>> concerned.  However Chris might have a different opinion - I
> >>>> think he introduced it.
> >>>
> >>> I don't think I introduced it (was it Devang?).
> >>
> >> Yup. PR 1278
> >
> > Ok!  Can you please fix it to index by GCC type?  There is a many to
> > one mapping between gcc types and llvm types.
>
> This is tricky and probably won't work. Padding info is in llvm struct
> type and CopyAggregate() is operating on llvm type. There is not any
> way to map llvm type back to gcc type.  Am I missing something ?
>
> -
> Devang
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 15 Feb 2008 11:21:41 -0800
> From: Chris Lattner <sabre at nondot.org>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <8A9142EB-F978-4CCE-8550-5F805BDFAA07 at nondot.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On Feb 15, 2008, at 11:17 AM, Devang Patel wrote:
> >> Ok!  Can you please fix it to index by GCC type?  There is a many to
> >> one mapping between gcc types and llvm types.
> >
> > This is tricky and probably won't work. Padding info is in llvm struct
> > type and CopyAggregate() is operating on llvm type. There is not any
> > way to map llvm type back to gcc type.  Am I missing something ?
>
> EmitAggregateCopy has the gcc type.  It would be reasonable to have
> CopyAggregate walk the GCC type in parallel with the llvm type, at
> least in simple cases.  In more complex cases, it could give up.
>
> -Chris
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 15 Feb 2008 11:22:47 -0800
> From: Dale Johannesen <dalej at apple.com>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1 at apple.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> 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
> >>>>>> 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 rid of the padding info as far as I'm
> >>>>> concerned.  However Chris might have a different opinion - I
> >>>>> think he introduced it.
> >>>>
> >>>> I don't think I introduced it (was it Devang?).
> >>>
> >>> Yup. PR 1278
> >>
> >> Ok!  Can you please fix it to index by GCC type?  There is a many to
> >> one mapping between gcc types and llvm types.
> >
> > This is tricky and probably won't work. Padding info is in llvm struct
> > type and CopyAggregate() is operating on llvm type. There is not any
> > way to map llvm type back to gcc type.  Am I missing something ?
>
>
> I don't think so, I have reached the same conclusion.  You can pass
> the gcc type into CopyAggregate, but it's recursive, and there's no
> way to get the gcc type for the fields.  You would have to walk the
> gcc type in parallel with the llvm type, which at best involves
> duplicating a lot of code and is quite error prone.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 15 Feb 2008 11:27:42 -0800
> From: Dale Johannesen <dalej at apple.com>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: Dale Johannesen <dalej at apple.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <86CE380D-44AB-4035-9E7C-2DCD85308BDA at apple.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> 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:
> >>>>
> >>>>>>> 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 rid of the padding info as far as I'm
> >>>>>> concerned.  However Chris might have a different opinion - I
> >>>>>> think he introduced it.
> >>>>>
> >>>>> I don't think I introduced it (was it Devang?).
> >>>>
> >>>> Yup. PR 1278
> >>>
> >>> Ok!  Can you please fix it to index by GCC type?  There is a many to
> >>> one mapping between gcc types and llvm types.
> >>
> >> This is tricky and probably won't work. Padding info is in llvm
> >> struct
> >> type and CopyAggregate() is operating on llvm type. There is not any
> >> way to map llvm type back to gcc type.  Am I missing something ?
> >
> >
> > I don't think so, I have reached the same conclusion.  You can pass
> > the gcc type into CopyAggregate, but it's recursive, and there's no
> > way to get the gcc type for the fields.  You would have to walk the
> > gcc type in parallel with the llvm type, which at best involves
> > duplicating a lot of code and is quite error prone.
>
> ...but giving up in this case is easy enough, ok, I can do that.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Feb 2008 11:39:06 -0800
> From: Chris Lattner <sabre at nondot.org>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <9345E8E7-503D-483F-90DD-1DA6FD64B6F3 at nondot.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Feb 15, 2008, at 11:27 AM, Dale Johannesen wrote:
>
> >> I don't think so, I have reached the same conclusion.  You can pass
> >> the gcc type into CopyAggregate, but it's recursive, and there's no
> >> way to get the gcc type for the fields.  You would have to walk the
> >> gcc type in parallel with the llvm type, which at best involves
> >> duplicating a lot of code and is quite error prone.
> >
> > ...but giving up in this case is easy enough, ok, I can do that.
>
> Cool, thanks Dale!  I think it would be reasonable to give up in
> nested struct cases, etc.  We can always improve it later, and that
> will get us the obvious case in PR1278.
>
> -Chris
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 15 Feb 2008 11:47:47 -0800
> From: "Ted Neward" <ted at tedneward.com>
> Subject: Re: [LLVMdev] Question on link error
> To: "'Anton Korobeynikov'" <asl at math.spbu.ru>,  "'LLVM Developers
>        Mailing List'" <llvmdev at cs.uiuc.edu>
> Message-ID: <017001c8700b$a8172760$f8457620$@com>
> Content-Type: text/plain;       charset="windows-1250"
>
> I am *more* than willing to believe it's an environment/configuration
> error,
> so if you can't repro it, let's assume the problem is somewhere on my end.
>
> FWIW, I took the 2.2 release from the website, the GCC 4.2 release from
> the
> website, and tried to follow the README.LLVM directions (build LLVM 2.2,
> configure gcc in the obj directory, make and make install), then ran
> through
> the hello steps. Only the lli step fails.
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
>
> > -----Original Message-----
> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> > On Behalf Of Anton Korobeynikov
> > Sent: Friday, February 15, 2008 3:52 AM
> > To: LLVM Developers Mailing List
> > Subject: Re: [LLVMdev] Question on link error
> >
> > Hello, Ted
> >
> > > __main is supposed to be inside hello.bc, so why can t lli find it?
> > No, it shouldn't be there. On targets, which lacks init sections (for
> > example, all win-based, like mingw & cygwin) __main is used to call
> > static constructors and relevant stuff.
> >
> > The call to __main is assembled early in the main routine before the
> > actual code will be executed. I'll try to look into this problem today.
> >
> > --
> > WBR, Anton Korobeynikov
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.516 / Virus Database: 269.20.5/1278 - Release Date:
> > 2/14/2008 10:28 AM
> >
> >
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.20.6/1280 - Release Date: 2/15/2008
> 9:00 AM
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 15 Feb 2008 21:01:33 +0100 (CET)
> From: Roman Levenstein <romixlev at yahoo.com>
> Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting &
>        SubRegisters)
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <572290.31048.qm at web56312.mail.re3.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> 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,
> > >>>
> > >>> 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.
>
> 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
> splitted intervals are added to unhandled set. Thus they get a chance
> to get physical registers assigned to them, independently. So,
> actually, they are not quite "spilled" intervals (since they are not
> really spilled and located in memory) and may get a physical register.
> Is my understanding of the algorithm correct so far?
>
> What I don't quite understand is the following:
> Why do live intervals with an allocated stack slot should also always
> have a physical register assigned to them? How should a register
> allocator decide, which physical register should be used for that?
>
> For example, in my version of Sarkar's Extended Linear Scan I sometimes
> spill the whole live interval. So, I assign a stack slot to it. But
> LLVM requires also a physical register to be assigned to each such live
> interval as well. How do I decide which physical register should be
> taken? Why can't the local spiller or the former rewriteFunction() part
> of the RegAllocLinearScan find out on their own which of the currently
> available for allocation physical registers should be taken at a given
> point for a reload or for a spilling operation for a given spilled live
> interval? Wouldn't it be more convenient? You just say that the
> interval is spilled and the rest is done "by magic"? Or may be I'm
> missing something about how spilling currently works in LLVM?
>
> Thanks in advance for any clarification of this issue.
>
> -Roman
>
>
>      Lesen Sie Ihre E-Mails auf dem Handy.
> www.yahoo.de/go
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 15 Feb 2008 12:21:08 -0800 (PST)
> From: Fernando Magno Quintao Pereira <fernando at CS.UCLA.EDU>
> Subject: Re: [LLVMdev] LiveInterval spilling (was LiveInterval
>        Splitting & SubRegisters)
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <Pine.SOC.4.64.0802151220110.12284 at cheetah.cs.ucla.edu>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
> 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 := 1           a(R1) := 1 // a is assigned to R1
>   |              // store R1 into M1
>   |
>   |              // 'a' is spilled into stack slot M1
>   |
>   |              // assign 'a' to R2, and load M1 into R2
> b := a           b(Rx) := a(R2)
>   |
>   |
>   |
>   |
>   |              // assign 'a' to R3, and load M1 into R3
> c := a           c(Ry) := a(R3)
>
> So, the register is necessary for doing the reloading. Sometimes it is
> possible to avoid the reloading with instruction folding, but this is not
> always 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
> > splitted intervals are added to unhandled set. Thus they get a chance
> > to get physical registers assigned to them, independently. So,
> > actually, they are not quite "spilled" intervals (since they are not
> > really spilled and located in memory) and may get a physical register.
> > Is my understanding of the algorithm correct so far?
> >
> > What I don't quite understand is the following:
> > Why do live intervals with an allocated stack slot should also always
> > have a physical register assigned to them? How should a register
> > allocator decide, which physical register should be used for that?
> >
> > For example, in my version of Sarkar's Extended Linear Scan I sometimes
> > spill the whole live interval. So, I assign a stack slot to it. But
> > LLVM requires also a physical register to be assigned to each such live
> > interval as well. How do I decide which physical register should be
> > taken? Why can't the local spiller or the former rewriteFunction() part
> > of the RegAllocLinearScan find out on their own which of the currently
> > available for allocation physical registers should be taken at a given
> > point for a reload or for a spilling operation for a given spilled live
> > interval? Wouldn't it be more convenient? You just say that the
> > interval is spilled and the rest is done "by magic"? Or may be I'm
> > missing something about how spilling currently works in LLVM?
> >
> > Thanks in advance for any clarification of this issue.
> >
> > -Roman
> >
> >
> >      Lesen Sie Ihre E-Mails auf dem Handy.
> > www.yahoo.de/go
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 44, Issue 47
> ***************************************
>



-- 
Sébastien Loisel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080215/a88fb674/attachment.html>