If a cmpxchg specifies acquire or seq_cst on failure, make sure we generate code consistent with that ordering even if the success ordering is not acquire/seq_cst.
At one point, it was ambiguous whether this sort of construct was valid, but the C++ standad and LLVM now accept arbitrary combinations of success/failure orderings.
This doesn't address the corresponding issue in AtomicExpand. (This was reported as https://bugs.llvm.org/show_bug.cgi?id=33332 .)
I think this is a confusing API now. The reason it made sense to have getOrdering return the success ordering for a cmpxchg before is because that was always stronger than the failure ordering. So, using the success order was a safe "default" ordering. That's no longer the case.
Maybe we should have getOrdering should return the merged ordering, and rename the existing getOrdering to getSuccessOrdering.
Or, actually I like this better: remove getOrdering entirely, by renaming to getSuccessOrdering. Then we'll have getSuccessOrdering, getFailureOrdering, and getMergedOrdering. That's much clearer. (And, yes, this does still make sense for non-cmpxchg -- they always succeed, so the success ordering is the only relevant thing for them.)