[LLVMdev] LLVMdev Digest, Vol 44, Issue 47
Sebastien Loisel
loisel at temple.edu
Fri Feb 15 12:31:34 PST 2008
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 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: LLVMdev Digest, Vol 44, Issue 47 (Sebastien Loisel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 15 Feb 2008 15:28:46 -0500
> From: "Sebastien Loisel" <loisel at temple.edu>
> Subject: Re: [LLVMdev] LLVMdev Digest, Vol 44, Issue 47
> To: llvmdev at cs.uiuc.edu
> Message-ID:
> <b7975ab80802151228o7bbefb9clfeda614c282f0991 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.cs.uiuc.edu/pipermail/llvmdev/attachments/20080215/a88fb674/attachment.html
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 44, Issue 48
> ***************************************
>
--
Sébastien Loisel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080215/05ce4791/attachment.html>
More information about the llvm-dev
mailing list