llvm dev - Mar 2016 - Question on ATOMIC_CMP_SWAP results being sign or zero extended

Hello,

I'm trying to fix a wrong code bug for MIPS regarding
ATOMIC_CMP_SWAP_WITH_SUCCESS and partial word atomics.

Nodes of that type get legalized into ATOMIC_CMP_SWP with a SETCC of the result
and the comparison value. For MIPS this  introduces a bug as partial word
atomics have their results sign-extended and can be compared to unsigned value.

Are the results of ATOMIC_CMP_SWAP_WITH_SUCCESS and ATOMIC_CMP_SWAP defined or
expected to be zero-extended or sign-extended? Or is it just "do something
sensible for your target"?

Looking at the X86, PowerPC and AArch64 backends seems to show that they
don't sign-extend the results of ATOMIC_CMP_SWAP*.

Thanks,
Simon

Hi Simon,

On 15 March 2016 at 09:39, Simon Dardis via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Are the results of ATOMIC_CMP_SWAP_WITH_SUCCESS and ATOMIC_CMP_SWAP defined
or expected to be zero-extended or sign-extended? Or is it just "do
something sensible for your target"?
Interesting. We actually don't seem to do any of the extensions
required for a type-legalized SETCC (particularly truncating "desired"
properly), so it's probably buggy on existing targets too. The output
of

define {i32, i1} @foo(i32* %addr, i32 %l, i32 %r, i32 %new) {
  %desired = add i32 %l, %r
  %res = cmpxchg i32* %addr, i32 %desired, i32 %new seq_cst seq_cst
  ret {i32, i1} %res
}

looks very suspicious on PowerPC. It seems entirely reasonable that
which extension is used could be controlled by a callback to
ISelLowering.

Cheers.

Tim.