This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Eagerly evaluate __atomic_is_lock_free to 0 for oversized types


On Mon, Feb 10, 2020 at 8:40 PM Andrew Pinski <pinskia@gmail.com> wrote:
>
> 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?

Oh it is this, you quoted the wrong function which made things more complicated.

/* Return a one or zero if it can be determined that object ARG1 of size ARG
   is lock free on this architecture.  */

static tree
fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
{
  if (!flag_inline_atomics)
    return NULL_TREE;

  /* If it isn't always lock free, don't generate a result.  */
  if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
    return boolean_true_node;

  return NULL_TREE;
}

--- CUT ---

Thanks,
Andrew Pinski

>   /* 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]