[PATCH] D18201: Switch over targets to use AtomicExpandPass, and clean up target atomics code.
James Y Knight via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 16 20:49:49 PDT 2016
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.
More information about the llvm-commits