Re: [patch] Provide a can_compare_and_swap_p target hook.

[Andrew MacLeod]

On 11/06/2014 01:23 PM, Andrew Haley wrote:
On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
It looks like java is deciding whether or not GCC can inline atomic
operations or not, and if it can't, doesn't want the atomic
operations...   which presumably means there is no dependency on
libatomic at runtime.
A call to can_compare_and_swap_p(mode) is analogous to a compile time
version of folding atomic_always_lock_free(mode) to a constant...
Frankly that seems like a reasonable question for some front end to
ask...  and elect not to emit atomic calls if so desired. (which is what
java is doing I think)

whether it still needs to do that is a question for some java person.
I did it because some targets did not have library support for some
builtins, so a compile would fail with a (to a Java programmer)
baffling error message.

The Java operations certainly should use the generic builtins.


Thanks Andrew


1) Given that the compiler *always* provides support via libatomic now 
(even if it is via locks), does that mean that VMSupportsCS8_builtin() 
should always return true?

or should we map to that a call to __atomic_always_lock_free() ? (that 
always gets folded to a true or false at compile time)  my guess is the 
latter?

2) and in compareAndSwapLong_builtin(), thre is a wonky bit:

/* We don't trust flag_use_atomic_builtins for multi-word compareAndSwap.
     Some machines such as ARM have atomic libfuncs but not the multi-word
     versions.  */
  if (can_compare_and_swap_p (mode,
                              (flag_use_atomic_builtins
                               && GET_MODE_SIZE (mode) <= UNITS_PER_WORD)))
    <..> /* generate 8 byte CAS  */

I gather we dont need to do anything special here anymore either?     As 
an observation of inconsistency,
compareAndSwapObject_builtin  doesn't do that check before calling the 8 
byte CAS :

machine_mode mode = TYPE_MODE (ptr_type_node);
  if (can_compare_and_swap_p (mode, flag_use_atomic_builtins))
  {
    tree addr, stmt;
    enum built_in_function builtin;

    UNMARSHAL5 (orig_call);
    builtin = (POINTER_SIZE == 32
               ? BUILT_IN_SYNC_BOOL_COMPARE_AND_SWAP_4
               : BUILT_IN_SYNC_BOOL_COMPARE_AND_SWAP_8);

    addr = build_addr_sum (value_type, obj_arg, offset_arg);



3) And finally, is flag_use_atomic_builtins suppose to turn them off 
completely?  Right now it is passed in  to the second parameter of 
can_compare_and_swap_p, which really just says can we compare and swap 
without calling a libfunc..   so currently if the flag is 0, but there 
is native support, the call is generated anyway.   should that condition 
really be:

if (flag_use_atomic_builtins)
  {
   <...> /* generate atomic call */
 }


Thanks
Andrew.