The patch that fixes delay slot filling looks fine.<br><br>As for the second patch, we should reserve GP only when it is needed to access small section.<br>I created a patch to fix this. Does it work for you?<br><br>I also attached a short test program. You can compile it with this command:<br>
<br>$ llc smallsection1.ll -o - -relocation-model=static<br><br><div class="gmail_quote">On Mon, Aug 20, 2012 at 1:48 PM, Carl Norum <span dir="ltr"><<a href="mailto:carl@lytro.com" target="_blank">carl@lytro.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Forwarding these patch to the commits list - any comments?</div><div>
<br></div><div>Thanks!</div><div><br></div><div>-- Carl</div><div><br></div><br><div>
Begin forwarded message:</div><div><br><blockquote type="cite"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span><b>From: </b></span><span style="font-family:'Helvetica';font-size:medium">Carl Norum <<a href="mailto:carl@lytro.com" target="_blank">carl@lytro.com</a>><br>
</span></div><div class="im"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span><b>Subject: </b></span><span style="font-family:'Helvetica';font-size:medium"><b>Re: [LLVMdev] MIPS & GP register</b><br>
</span></div></div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span><b>Date: </b></span><span style="font-family:'Helvetica';font-size:medium">August 17, 2012 4:40:50 PM PDT<br>
</span></div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span><b>To: </b></span><span style="font-family:'Helvetica';font-size:medium">LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
</span></div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span><b>Cc: </b></span><span style="font-family:'Helvetica';font-size:medium">Akira Hatanaka <<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>><br>
</span></div><div class="im"><br><div style="word-wrap:break-word"><div><br></div><div>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?</div>
<div><br></div><div>-- Carl</div><div><br></div><div><br></div></div></div></blockquote></div></div><br><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"></div></blockquote></div>
</div><br><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><div><br><div><div>On Aug 17, 2012, at 4:01 PM, Carl Norum wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">
<br><div><div>On Aug 17, 2012, at 2:36 PM, Akira Hatanaka wrote:</div><br><blockquote type="cite">(forwarding to llvm-dev)<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Akira Hatanaka</b> <span dir="ltr"><<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>></span><br>

Date: Fri, Aug 17, 2012 at 2:35 PM<br>Subject: Re: [LLVMdev] MIPS & GP register<br>To: Carl Norum <<a href="mailto:carl@lytro.com" target="_blank">carl@lytro.com</a>><br><br><br>Will something like this fix the problem?<br>
<br>
if (!Subtarget.isLinux()) {<br>  reserve GP and GP_64<br>}<br></div></blockquote><blockquote type="cite"><br></blockquote><div><blockquote type="cite"><div class="gmail_quote">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.<br>
</div></blockquote></div><div><br></div><div>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.</div>
<div><br></div><div>-- Carl</div><div><br></div><br><blockquote type="cite"><div class="gmail_quote"><br><div class="gmail_quote"><div>On Wed, Aug 15, 2012 at 10:17 PM, Carl Norum <span dir="ltr"><<a href="mailto:carl@lytro.com" target="_blank">carl@lytro.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>


<br>
Hi LLVM MIPS people,<br>
<br>
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:<br>





<br>
> ------------------------------------------------------------------------<br>
> r156694 | ahatanak | 2012-05-11 20:21:18 -0700 (Fri, 11 May 2012) | 3 lines<br>
><br>
> Stop reserving register $gp. Do not call isGPFI to check whether a frame object<br>
> is the $gp save slot.<br>
<br>
<br>
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.<br>





<br>
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):<br>





<br>
>     -march=mips32r2<br>
>     -mtune=4kem<br>
>     -msoft-float<br>
>     -EL<br>
><br>
>     -Xclang -triple -Xclang mipsel-sde-elf<br>
>     -Xclang -mrelocation-model -Xclang static<br>
><br>
>     -Xclang -mllvm -Xclang -mips-ssection-threshold=0<br>
>     -Xclang -mllvm -Xclang -enable-mips-delay-filler<br>
><br>
>     -Xassembler -G -Xassembler 0 -g<br>
><br>
>     -funsigned-char<br>
>     -fshort-wchar<br>
>     -fno-zero-initialized-in-bss<br>
>     -fasynchronous-unwind-tables<br>
>     -ffunction-sections<br>
>     -fdata-sections<br>
><br>
>     -Oz<br>
<br>
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?<br>





<br>
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?<br>





<br>
Thanks for any tips & advice!<br>
<span><font color="#888888"><br>
--<br>
Carl Norum<br>
<a href="mailto:carl@lytro.com" target="_blank">carl@lytro.com</a><br>
<br>
<br>
</font></span><br></div></div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></div></blockquote></div><br>
</div><br>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></div></blockquote></div><br></div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br>