Re: [PATCH] Fix IA-64 __sync_*_compare_and_swap_si intrinsic

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Mar 24, 2003 at 11:36:09AM -0800, David Mosberger wrote:
>   Jakub> So, say mov ar.ccv = -30 is necessarily wrong before
>   Jakub> cmpxchg4.acq, since the zero-extended load will never have
>   Jakub> topmost 32 bits set.  fetch_and_op and op_and_fetch IMHO can
>   Jakub> stay as is, since they do emit the memory load (which
>   Jakub> zero-extends) too and store that into ar.ccv.  I wonder
>   Jakub> whether removing the mode from cmpxchg_acq_si is ok (a
>   Jakub> warning is emitted for it). Should I create two SImode insn
>   Jakub> patterns instead, one with SImode and one with DImode ccv?
>   Jakub> Ok to commit? 3.3 too?
> 
> Isn't the problem that the prototypes are wrong?  For example:
> 
> extern int __sync_val_compare_and_swap_si (int *, int, int);
> 
> Would it work to change ia64_init_builtins() to change the types from
> "integer_type_node" to "unsigned_type_node"?  I think it should.

No, that doesn't work (even tried it). The thing is, if the ar.ccv
assignment is done in SImode, ie.
(set (reg:SI ar.ccv) (something:SI ...))
then the upper bits can contain anything.
If oldval is say -30U, it will still do
mov ar.ccv = -30
no matter if oldval is int or unsigned int, instead of the needed:
movl rX = 4294967266;;
mov ar.ccv = rX.
Similarly, if oldval is addition of two unsigned int variables
(say one with value -20U and one -10U), it still can (and will) do:
ld4 rX = [rXaddr]
ld4 rY = [rYaddr];;
add rZ = rX, rY;;
mov ar.ccv = rZ
which doesn't guarantee all upper 32-bits zero.

How the ia64intrin.h prototypes should look exactly is a different matter,
particularly what exactly the ABI requires.

	Jakub