[LLVMdev] LLVMdev Digest, Vol 44, Issue 47
Tanya M. Lattner
tonic at nondot.org
Fri Feb 15 12:48:35 PST 2008
> 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.
Yes, edit your mailman subscription options.
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-Tanya
>
> 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
>> ***************************************
>>
>
>
>
>
More information about the llvm-dev
mailing list