[PATCH] D41791: [DAG Legalization] Zero-extend the value compared in cmpxchg

Nemanja Ivanovic via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jan 7 07:24:20 PST 2018

nemanjai added a comment.

In https://reviews.llvm.org/D41791#969091, @efriedma wrote:

> (It looks like https://reviews.llvm.org/D41798 fixes your testcase?)

Almost. I've added a detailed comment there regarding why it doesn't fix the whole problem.

Comment at: lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:236
-  SDValue Op2 = GetPromotedInteger(N->getOperand(2));
+  SDValue Op2 = ZExtPromotedInteger(N->getOperand(2));
   SDValue Op3 = GetPromotedInteger(N->getOperand(3));
efriedma wrote:
> 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().
I agree that this seems a bit confusing - i.e. why is one operand zero-extended whereas the other operand is essentially "any-extended". However, I think that the "store" operand of the atomic compare and exchange should be extended according to `getExtendForAtomicOps()` whereas the "compare" operand should always be zero-extended.
The reason I think this is that the compare operand is essentially used for equality comparison similarly to SETEQ/SETNE for SETCC, whereas the other operand is used to load and store the value - so it should be handled the way a target desires to handle atomics.



More information about the llvm-commits mailing list