(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. 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/f13b4ca0/attachment.html>
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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/815cd8f3/attachment.html>
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/fd5e13f8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: delay-filler.patch Type: application/octet-stream Size: 1101 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/fd5e13f8/attachment.obj> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/fd5e13f8/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: reserve-gp.patch Type: application/octet-stream Size: 760 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/fd5e13f8/attachment-0001.obj> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/fd5e13f8/attachment-0002.html>