[llvm-commits] MIPS & GP register

Tue Aug 21 20:21:27 PDT 2012

Committed r162339 & r162340.

I have asked the person who worked on the clang driver to review the clang
patch. He will be back next week.

Thank you again for the patch.

On Tue, Aug 21, 2012 at 11:03 AM, Carl Norum <carl at lytro.com> wrote:

>
> Worked fine here on our project, I say go for it.  Can you check both in?
>  I also have an outstanding patch to support the -G flag for clang - that
> one I sent over to the cfe-commits list.  I didn't hear anything back on
> that, but I'll go ping it now.
>
> -- Carl
>
> Confidentiality Notice:  This e-mail, including all attachments, is confidential
> information of Lytro, Inc. If the reader of this e-mail is not the intended
> recipient or its authorized agent, the reader is hereby notified that any
> dissemination, distribution or copying of this e-mail is prohibited. If you
> have received this e-mail in error, please notify the sender by replying to
> this message and delete this e-mail immediately.
>
>
>
>
> On Aug 20, 2012, at 5:05 PM, Carl Norum wrote:
>
>
> Thanks - I'll give your patch a try (maybe tomorrow at the earliest) and
> let you know how it works out.
>
> -- Carl
>
>
> Confidentiality Notice:  This e-mail, including all attachments, is confidential
> information of Lytro, Inc. If the reader of this e-mail is not the intended
> recipient or its authorized agent, the reader is hereby notified that any
> dissemination, distribution or copying of this e-mail is prohibited. If you
> have received this e-mail in error, please notify the sender by replying to
> this message and delete this e-mail immediately.
>
>
>
>
> On Aug 20, 2012, at 3:13 PM, Akira Hatanaka wrote:
>
> The patch that fixes delay slot filling looks fine.
>
> As for the second patch, we should reserve GP only when it is needed to
> access small section.
> I created a patch to fix this. Does it work for you?
>
> I also attached a short test program. You can compile it with this command:
>
> $ llc smallsection1.ll -o - -relocation-model=static
>
> On Mon, Aug 20, 2012 at 1:48 PM, Carl Norum <carl at lytro.com> wrote:
>
>>
>> Forwarding these patch to the commits list - any comments?
>>
>> Thanks!
>>
>> -- Carl
>>
>>
>> Begin forwarded message:
>>
>> *From: *Carl Norum <carl at lytro.com>
>> *Subject: **Re: [LLVMdev] MIPS & GP register*
>> *Date: *August 17, 2012 4:40:50 PM PDT
>> *To: *LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>> *Cc: *Akira Hatanaka <ahatanak at gmail.com>
>>
>>
>> OK here are some updated patches.  Thanks for checking them out.  Is this
>> the right place to send them, or should I be sending to llvm-commits?
>>
>> -- Carl
>>
>>
>>
>>
>>
>> On Aug 17, 2012, at 4:01 PM, Carl Norum wrote:
>>
>>
>> On Aug 17, 2012, at 2:36 PM, Akira Hatanaka wrote:
>>
>> (forwarding to llvm-dev)
>>
>> ---------- Forwarded message ----------
>> From: Akira Hatanaka <ahatanak at gmail.com>
>> Date: Fri, Aug 17, 2012 at 2:35 PM
>> Subject: Re: [LLVMdev] MIPS & GP register
>> To: Carl Norum <carl at lytro.com>
>>
>>
>> Will something like this fix the problem?
>>
>> if (!Subtarget.isLinux()) {
>>   reserve GP and GP_64
>> }
>>
>>
>> To improve code, we have stopped reserving GP as a dedicated global
>> register and have made it available to the register allocator. This works
>> if we can initialize GP at the entry of every function, as we do now, but
>> will not otherwise.
>>
>>
>> Yes that's fine as long as it works for our triple.  I'm not quite sure
>> how that would work out.  Our target is bare-metal mips.  If I had my
>> druthers we would freely use GP as well, but we have some vendor-provided
>> libraries that rely on it not getting whacked.  Maybe someday I can go in
>> and rebuild all that stuff, but it's definitely a future project for us.
>>
>> -- Carl
>>
>>
>>
>> On Wed, Aug 15, 2012 at 10:17 PM, Carl Norum <carl at lytro.com> wrote:
>>
>>>
>>> Hi LLVM MIPS people,
>>>
>>> I've been trying to keep track of the MIPS backend in order to
>>> eventually switch to clang/llvm from GCC for building our camera software.
>>>  We've been using a build at revision 156432 for some time with no
>>> problems.  I synced up to TOT clang/llvm today (revision 162004) to see if
>>> any optimizations had been improved, etc.  The build I made with it started
>>> crashing cameras immediately.  I managed to track it down to the removal of
>>> GP from the list of reserved registers in this checkin:
>>>
>>> >
>>> ------------------------------------------------------------------------
>>> > r156694 | ahatanak | 2012-05-11 20:21:18 -0700 (Fri, 11 May 2012) | 3
>>> lines
>>> >
>>> > Stop reserving register $gp. Do not call isGPFI to check whether a
>>> frame object
>>> > is the $gp save slot.
>>>
>>>
>>> Adding Mips::GP back into the reserved register list made everything go
>>> back to normal.  I'm guessing that GP was removed from the list on purpose,
>>> so I don't think my change is necessarily correct, but it did fix our
>>> problems.  I have attached a patch for reference anyway.
>>>
>>> Are there some flags we should be passing to make sure GP doesn't get
>>> stomped on?  Actually, we generated the list of flags we use without much
>>> rhyme or reason, to be honest.  Here's what we have and was working
>>> (filtered a bit to remove -I, -D, -W flags and sorted out by flag type and
>>> in order of what I think matters):
>>>
>>> >     -march=mips32r2
>>> >     -mtune=4kem
>>> >     -msoft-float
>>> >     -EL
>>> >
>>> >     -Xclang -triple -Xclang mipsel-sde-elf
>>> >     -Xclang -mrelocation-model -Xclang static
>>> >
>>> >     -Xclang -mllvm -Xclang -mips-ssection-threshold=0
>>> >     -Xclang -mllvm -Xclang -enable-mips-delay-filler
>>> >
>>> >     -Xassembler -G -Xassembler 0 -g
>>> >
>>> >     -funsigned-char
>>> >     -fshort-wchar
>>> >     -fno-zero-initialized-in-bss
>>> >     -fasynchronous-unwind-tables
>>> >     -ffunction-sections
>>> >     -fdata-sections
>>> >
>>> >     -Oz
>>>
>>> Does that stuff looks like it makes sense?  A once-over by someone with
>>> some expertise would be much appreciated.  I also see in the LLVM 3.1
>>> release notes that "MIPS32 little-endian direct object code emission is
>>> functional" - does that mean we don't need a supporting GCC installation
>>> anymore?  What do we do to enable this feature?  Would our flags above need
>>> to change if we do that?
>>>
>>> On the runtime side, clang/llvm generated a bunch of calls to floating
>>> point functions that our old-timey gcc library didn't contain -
>>> specifically __floatundidf and __floatundisf and a couple of other
>>> similarly named routines.  We managed to get them out of a newer libgcc,
>>> but couldn't find anything in clang/llvm that had them.  I found them in
>>> compiler-rt, but from what I gather that doesn't work for MIPS yet?
>>>
>>> Thanks for any tips & advice!
>>>
>>> --
>>> Carl Norum
>>> carl at lytro.com
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
> <smallsection.patch><smallsection1.ll>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120821/700b5e2c/attachment.html>