[PATCH] D41798: [LegalizeDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS legalization.

[Nemanja Ivanovic via Phabricator via llvm-commits]

nemanjai added a comment.

> Sure, the operands will have been any-extended from i8/i16 to i32.  But the target knows that this happened, because it knows that this is a i8/i16 ATOMIC_CMP_SWAP (via getMemoryVT).  In that case, if it actually requires a particular sign- or zero-extended version of the original i8/i16 constant, it can still do the appropriate in-reg extension from the any-extended i32 value it got.

Oh OK, of course. I mentioned in the original patch that I can certainly fix this in the PPC back end. I imagine that other back ends have done the same thing one way or another (or have a bug in this they don't know about just as PPC does). However, I ultimately don't see the utility in type-legalization ignoring how the target wants these inputs extended and doing an any-extend when the target is going to have to pick one down the line. And the target has already stated how it wants atomics extended in that TLI hook.

Of course, if there's a good reason to keep these as any-extends in type-legalization, I don't mind fixing it in the back end.


Repository:
  rL LLVM

https://reviews.llvm.org/D41798