Re: Eagerly evaluate __atomic_is_lock_free to 0 for oversized types

[Andrew Pinski <pinskia at gmail dot com>]

On Mon, Feb 10, 2020 at 8:35 PM Fangrui Song <i@maskray.me> wrote:
>
> GCC never evaluates __atomic_is_lock_free to 0. (gcc/builtins.c:fold_builtin_atomic_always_lock_free)

Huh?
  /* We need a corresponding integer mode for the access to be lock-free.  */
  size = INTVAL (expand_normal (arg0)) * BITS_PER_UNIT;
  if (!int_mode_for_size (size, 0).exists (&mode))
    return boolean_false_node;
...
  /* If the object has smaller alignment, the lock free routines cannot
     be used.  */
  if (type_align < mode_align)
    return boolean_false_node;
  /* Check if a compare_and_swap pattern exists for the mode which represents
     the required size.  The pattern is not allowed to fail, so the existence
     of the pattern indicates support is present.  Also require that an
     atomic load exists for the required size.  */
  if (can_compare_and_swap_p (mode, true) && can_atomic_load_p (mode))
    return boolean_true_node;
  else
    return boolean_false_node;


Thanks,
Andrew Pinski



> I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for apparently oversized types.
> This helps some platforms to avoid a dependency on libatomic.
>
> Either of the following choices can move my patch https://reviews.llvm.org/D72579 forward:
>
> * GCC will like do the same
> * GCC is committed to not extend __atomic_is_lock_free in a clang incompatible way.