public inbox for
 help / color / mirror / Atom feed
From: Andrew Haley <>
To: Andrew MacLeod <>,
	       Richard Biener <>,
	       Richard Henderson <>,
	       gcc-patches <>
Cc: Jeff Law <>,
Subject: Re: [patch] Provide a can_compare_and_swap_p target hook.
Date: Fri, 07 Nov 2014 09:31:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 06/11/14 19:05, Andrew MacLeod wrote:
> 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?

Perhaps so.  The problem is that some targets can't do CAS on 64-bit

> 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 :

I believe that any machine which has 64-bit pointers and can do CAS
can do a 64-bit CAS.  I'm worried about 32-bit machines trying to do a
64-bit CAS.

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

I'm sorry, I really can't remember.  I can't think of any reason to
want to turn off builtin support.  You have to remember that all this
was written when our support for atomic builtins was seriously flaky
and we would just punt back to the user anything we hadn't written


  reply	other threads:[~2014-11-07  9:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
     [not found]           ` <>
2014-11-06 17:57             ` Andrew MacLeod
2014-11-06 18:23               ` Andrew Haley
2014-11-06 19:05                 ` Andrew MacLeod
2014-11-07  9:31                   ` Andrew Haley [this message]
2014-11-07 13:31                     ` Andrew MacLeod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).