[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));
> 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