Current legalization scheme extends input operands to atomic compare and exchange without specifying whether it's a sign or zero extension. However, this leads to bugs at least in PPC codegen. Of course, this can be fixed in the PPC back end, but it seems like the right thing to do would be to change this in legalization since the underlying comparison is an equality comparison. Operands of equality comparisons (SETCC) are zero-extended as well.
Since this affects other back ends as well, I'll send out an RFC about this to make sure this is safe/desirable for other targets.
The value operand to a store is implicitly truncated. The same thing happens for ATOMIC_LOAD_*. The same thing happens for the third operand of ATOMIC_CMP_SWAP. I think it's more confusing than helpful to add a special case for the compare operand of a compare. Atomic compare-and-swap doesn't zero-extend on all targets, anyway; see getExtendForAtomicOps().