[PATCH] D18201: Switch over targets to use AtomicExpandPass, and clean up target atomics code.

[James Y Knight via llvm-commits]

jyknight added a comment.

In http://reviews.llvm.org/D18201#377066, @t.p.northover wrote:

> On the plus side, GCC itself seems to be as buggy as clang (i.e. it loads with a cmpxchg16b with no loop to ensure success) so maybe real processors are more forgiving than the documentation suggests.


I don't think there's any bug there. according to the manual (the rest of the paragraph you quoted):

> To simplify the interface to the processor’s bus, the destination operand receives a write cycle without regard to the result of the comparison. The destination operand is written back if the comparison fails; otherwise, the source operand is written into the destination. (The processor never produces a locked read without also producing a locked write.)


That is, the lock cmpxchg16b instruction didn't //fail// if it returns false. It always does both a load and a store. It's just that if the comparison was false, it stores back the just-loaded value, instead of the new value.


http://reviews.llvm.org/D18201