Hi all, I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on sparc-sun-solaris2.10. Cheers, Nathan -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-sparcv9.patch Type: application/octet-stream Size: 8911 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100203/3f15e3e5/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-gcc-4.2-sparcv9.patch Type: application/octet-stream Size: 634 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100203/3f15e3e5/attachment-0001.obj>
On 02/03/2010 09:12 AM, Nathan Keynes wrote:> Hi all, > > I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on sparc-sun-solaris2.10. >It would be nice if there was a way to compile 32-bit code for sparcv9 too. For example with gcc I can do: no -m flags: sparcv8 (I think) -mcpu=ultrasparc -mtune=ultrasparc -> v9, 32-bit -m64 -> v9, 64-bit Also is there a way to auto-detect sparcv8, sparcv9, 32-bit mode, vs 64-bit mode? That would be nice if Sparc JIT support is ever added back. Best regards, --Edwin
Hello, Nathan> I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on sparc-sun-solaris2.10.I don't think this is good aproach. Why don't handle "v9" suffix in the same way as it is done for ARM / Thumb? You really don't need neither new target triplet for this nor another target class. Also, please use the standard coding convention inside llvm-gcc patch. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On 03/02/2010, at 10:16 PM, Anton Korobeynikov wrote:> Hello, Nathan > >> I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on sparc-sun-solaris2.10. > I don't think this is good aproach. Why don't handle "v9" suffix in > the same way as it is done for ARM / Thumb? You really don't need > neither new target triplet for this nor another target class.Hi Anton, I may need to clarify, sparcv9-* is used for the SPARCV9 ABI (ie 64-bit ABI), rather than the SPARCV9 CPU per se. It serves the same purpose as x86_64-* and powerpc64-*, which is to say it's associated with -m64, not -mcpu=v9 (although unsurprisingly -m64 does require a V9 or later CPU). I may be wrong, but I think the only distinction in ARM is between arm and thumb code, which do have distinct archtypes in Triple.h That said, I'm happy to change it however you like if you think it makes more sense, as long as we get distinct sparc-* and sparcv9-* triple strings in the end.> Also, please use the standard coding convention inside llvm-gcc patch.Oops, I messed the spacing on that one, sorry will fix. Cheers, Nathan
On Feb 2, 2010, at 11:12 PM, Nathan Keynes wrote:> Hi all, > > I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on sparc-sun-solaris2.10.Thanks, I applied the LLVM patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100201/095634.html This does seem like a good start. I tweaked it to stay in 80 columns and updated the testcase that started failing (you did run regression tests, right?). -Chris