[llvm-commits] MIPS & GP register
Carl Norum
carl at lytro.com
Mon Aug 20 17:05:03 PDT 2012
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/20120820/641fedc1/attachment.html>
More information about the llvm-commits
mailing list