[llvm-commits] Fwd: MIPS & GP register

Mon Aug 20 15:13:43 PDT 2012

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120820/d40e8dc9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smallsection.patch
Type: application/octet-stream
Size: 5143 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120820/d40e8dc9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smallsection1.ll
Type: application/octet-stream
Size: 584 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120820/d40e8dc9/attachment-0001.obj>