[patch] SPARCV9 subtarget support

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

llvm-sparcv9.patch (8.7 KB)

llvm-gcc-4.2-sparcv9.patch (634 Bytes)

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.

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

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

Hello, Nathan

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

I mean for arm we have arm vs armv4, armv5, armv6, armv6t2, armv7-*.
Same for thumb - thumb vs thumb2.

On sparc, sparc-foo-bar is the 32-bit ABI, and sparcv9-foo-bar is the 64-bit abi. Whether V9-specific instructions are used or not in 32-bit mode is controlled by -mattr=v9

-Chris