Use SSE for 128-bit atomic load/store on AMD CPU with AVX

[taiki-e]

As mentioned in #10 (comment), AMD is also going to guarantee this.

Refs: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=104688#c10

[taiki-e]

hmm...

https://gcc.gnu.org/bugzilla//show_bug.cgi?id=104688#c25

We do at least de-facto support atomics on UC memory because the ordering guarantees are a superset of cacheable memory, and 8-byte atomicity for aligned load/store is guaranteed even for non-cacheable memory types since P5 Pentium (and on AMD). (And lock cmpxchg16b is always atomic even on UC memory.)

But you're right that only Intel guarantees that 16-byte VMOVDQA loads/stores would be atomic on UC memory. So this change could break that very unwise corner-case on AMD which only guarantees that for cacheable loads/stores, and Zhaoxin only for WB.

But was anyone previously using 16-byte atomics on UC device memory? Do we actually care about supporting that? I'd guess no and no, so it's just a matter of documenting that somewhere.

Since GCC7 we've reported 16-byte atomics as being non-lock-free, so I hope people weren't using __atomic_store_n on device memory. The underlying implementation was never guaranteed.

[taiki-e]

bors r+

Given that GCC has already merged a similar patch (gcc-mirror/gcc@4a7a846), the subsequent discussion in that thread, the, and the scope of atomic operations in ARM and NVPTX, this should be able to be merged as is.

https://gcc.gnu.org/bugzilla//show_bug.cgi?id=104688#c27

e.g. x86 memory-type stuff, and that ARM assumes all cores are in the same inner-shareable cache-coherency domain, thus barriers are dmb ish not dmb sy and so on.

[bors]

Build succeeded:

• ci
• test (aarch64-apple-darwin)
• test (aarch64-unknown-linux-gnu)
• valgrind (aarch64-unknown-linux-gnu)