[LLVMdev] LLVMdev Digest, Vol 44, Issue 47

Fri Feb 15 12:37:22 PST 2008

Sebastien Loisel wrote:
> 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.
>   
Briefly looking over the admin interface, it seems that the mailer sends 
email when the digest reaches a certain size.  I am guessing, then, that 
llvm-dev has been busy as of late.

I believe I've changed your subscription so that you will receive no 
mails from the list, but you should still be able to send email to the 
list.  If you could send a test message to the list to make sure this is 
the case, I'd greatly appreciate it.

For those on digest, the digest size is currently 30 KB.  Is this 
reasonable for everyone, or should it be higher?

-- John T.

> 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<mailto:llvmdev-request at cs.uiuc.edu>> wrote:
> Send LLVMdev mailing list submissions to
>        llvmdev at cs.uiuc.edu<mailto: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<mailto:llvmdev-request at cs.uiuc.edu>
>
> You can reach the person managing the list at
>        llvmdev-owner at cs.uiuc.edu<mailto: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<mailto:dpatel at apple.com>>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
> Message-ID: <0C222846-383D-41DD-8229-4858BD1FD3A2 at apple.com<mailto: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<mailto:sabre at nondot.org>>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
> Message-ID: <8A9142EB-F978-4CCE-8550-5F805BDFAA07 at nondot.org<mailto: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<mailto:dalej at apple.com>>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
> Message-ID: <04308F30-2980-4F02-8FF7-E09DD4D0D9C1 at apple.com<mailto: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<mailto:dalej at apple.com>>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: Dale Johannesen <dalej at apple.com<mailto:dalej at apple.com>>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
> Message-ID: <86CE380D-44AB-4035-9E7C-2DCD85308BDA at apple.com<mailto: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<mailto:sabre at nondot.org>>
> Subject: Re: [LLVMdev] an llvm-gcc bug
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
> Message-ID: <9345E8E7-503D-483F-90DD-1DA6FD64B6F3 at nondot.org<mailto: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<mailto:ted at tedneward.com>>
> Subject: Re: [LLVMdev] Question on link error
> To: "'Anton Korobeynikov'" <asl at math.spbu.ru<mailto:asl at math.spbu.ru>>,  "'LLVM Developers
>        Mailing List'" <llvmdev at cs.uiuc.edu<mailto: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> [mailto: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<mailto:romixlev at yahoo.com>>
> Subject: [LLVMdev] LiveInterval spilling (was LiveInterval Splitting &
>        SubRegisters)
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
> Message-ID: <572290.31048.qm at web56312.mail.re3.yahoo.com<mailto: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<mailto: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<http://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<mailto:fernando at CS.UCLA.EDU>>
> Subject: Re: [LLVMdev] LiveInterval spilling (was LiveInterval
>        Splitting & SubRegisters)
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
> Message-ID: <Pine.SOC.4.64.0802151220110.12284 at cheetah.cs.ucla.edu<mailto: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<http://www.yahoo.de/go>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu<mailto: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<mailto:LLVMdev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 44, Issue 47
> ***************************************
>
>
>
> --
> Sébastien Loisel
>
>   