With respect of atomicrmw instruction, different targets have different
backend support. The front end can always emit the intruction, but when it comes
to the backend, the compiler could crash at instruction selection because the
target doesn't support the instruction/operator at all. Currently we don't have
a way in the front end to tell if an atomicrmw with specific operator and type
is supported. This patch adds a virtual function hasAtomicrmw to the class
TargetInfo and it is expected to be implemented by all targets accordingly.
In this way, we can always try to emit atomicrmw first because it has better
performance than falling back to CAS loop. Currently at the PoC stage, I only make
it in NVPTX, but if the community is happy with this change, I'll add to all the
targets.
For the long term, I'll seek a way to expand the instruction if the target doesn't
support it, probably similar to things in llvm/lib/CodeGen/AtomicExpandPass.cpp.
llvm_unreachable might be more appropriate here.