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,

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.