___atomic_XXX operations in libcxx for Sparc

Hi,

I am further developing the compiler back-end for Sparc for LLVM and I have some tests which the requirements of my project need to pass. They are using __atomic__XXX operations in libcxx, e.g. __atomic_compare_exchange_1, __atomic_fetch_xor_2 (among others).

These are not implemented currently for Sparc and if I understand http://libcxx.llvm.org/docs/[http://libcxx.llvm.org/docs/](http://libcxx.llvm.org/docs/) correctly, the relevant library containing these inbuilt functions are only implemented for i386 and x86_64.

However, I still need to get these working. There could be some resistance if I suggest using the GCC libraries to solve this problem, but I assume that it’s a very non-trivial task to port this library to Sparc.

Would my assumption be correct here? Could anyone give me an estimate for the amount of time it might take to port this? Even a scientific wild-ass guess (SWAG) would be better than what I could currently make.

What options do I have?

If I’m reading this situation incorrectly and it’s potentially trivial to implement these for Sparc, how might I go about this easily? If not, is it possible to use the GCC libraries to support this behaviour? Are there any other options?

Best Regards,
Chris Dewhurst,
University of Limerick.

Hello Chris,

I've asked an engineer from Oracle to answer:
but reply is not propagated back to this list, so here you are: ==========
Hi,

I’m assuming you are talking about porting LLVM to Solaris SPARC.

The library support for C++11 atomics feature is already available on Solaris 11. It is in a separate library called libatomic.so in /usr/lib though. You could try if this solves your immediate problem.

This library is not a Solaris system library, it comes from GCC 4.8. So you may need to install some GCC runtime library packages. If LLVM depends on this library, it is vulnerable to an ABI change, is it why you think there could be resistance? There is some effort going to to standardize the ABI of this library, not sure if you are interested?

The sized version (with a _n suffix) can also be implemented by back-end generating inlined code because all of them can be implemented with lock-free instructions, so it does not need locks or other meta data supported by a runtime library.

Thanks,

  • Bin