public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Abhishek Deb <adeb@nvidia.com>
To: Dinar Temirbulatov <dinar@kugelworks.com>,
	"libc-ports@sourceware.org"	<libc-ports@sourceware.org>
Cc: "joseph@codesourcery.com" <joseph@codesourcery.com>
Subject: RE: [Patch] ARM define atomic_exchange_acq/atomic_exchange_rel to __atomic_exchange_n
Date: Thu, 15 Aug 2013 21:46:00 -0000	[thread overview]
Message-ID: <0E42B6C0C4628E48B8DF5D3F3C8FCA8898F1F8BF56@HQMAIL02.nvidia.com> (raw)
In-Reply-To: <CANoaTN2hKTZ7GZCMsYqai25PHO7GLb56huLosR7+dgjAEK2FGQ@mail.gmail.com>

Dinar,

Apologies for delayed response, as I was on vacation. Your changes look in line with the MIPS changes. Since GCC 4.7. onwards _atomic builtins are provided, it's the right thing to do. I have not tested your changes, but I don't see anything obviously wrong. 

Following is how the compiled code looks like, when compiled with gcc 4.8

Atomic_exchange_rel : 

  c8:   f57ff05f        dmb     sy
  cc:   e1952f9f        ldrex   r2, [r5]
  d0:   e1851f93        strex   r1, r3, [r5]
  d4:   e3510000        cmp     r1, #0
  d8:   1afffffb        bne     cc 

Atomic_exchange_acq :

  94:   e1953f9f        ldrex   r3, [r5]
  98:   e1852f97        strex   r2, r7, [r5]
  9c:   e3520000        cmp     r2, #0
  a0:   1afffffb        bne     94 
  a4:   e3530000        cmp     r3, #0
  a8:   130f6c18        movwne  r6, #64536      ; 0xfc18
  ac:   f57ff05f        dmb     sy

So these changes look correct.

However, taking a deeper look into atomic_compare_and_exchange_acq/rel, following is how the compiled code looks like

  34:   f57ff05f        dmb     sy
  38:   e1903f9f        ldrex   r3, [r0]
  3c:   e3530000        cmp     r3, #0
  40:   1a000002        bne     50 
  44:   e1801f92        strex   r1, r2, [r0]
  48:   e3510000        cmp     r1, #0
  4c:   1afffff9        bne     38 
  50:   e3530000        cmp     r3, #0
  54:   f57ff05f        dmb     sy
  58:   1afffff5        bne     34 

As you can see it contains two memory barrier one in the beginning and one in the end. Is it because gcc's _sync_* builtin was used? The _atomic_* builtins provides users to specify memodel for each of the builtin functions. Hence, shouldn't _atomic_ builtin with appropriate memmodel be used to do an atomic_compare_and_exchange_acq/rel?

In other words for a acquire semantic the first dmb is redundant and for a release semantic the second one is redundant. I don't know what do you think.

Abhishek


-----Original Message-----
From: Dinar Temirbulatov [mailto:dinar@kugelworks.com] 
Sent: Tuesday, August 13, 2013 10:11 AM
To: libc-ports@sourceware.org
Cc: joseph@codesourcery.com; Abhishek Deb
Subject: [Patch] ARM define atomic_exchange_acq/atomic_exchange_rel to __atomic_exchange_n

Hello,
Following patch redefines atomic_exchange_acq/atomic_exchange_rel to __atomic_exchange_n for ARM, that allows for example to reduce number of instruction sequence for lll_unlock
from:
ldex, cmp, bne, stex, cmp, bne
to
ldex, stex, cmp, bne
, more on the issue here:
http://sourceware.org/bugzilla/show_bug.cgi?id=15640

This patch was tested on ARM a9 with glibc testsuite with no new regressions. OK to commit?

                       Thanks, Dinar.

  reply	other threads:[~2013-08-15 21:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 17:11 Dinar Temirbulatov
2013-08-15 21:46 ` Abhishek Deb [this message]
2013-08-16 22:57   ` Dinar Temirbulatov
2013-08-17  2:42     ` Abhishek Deb
2013-08-19 19:21       ` Dinar Temirbulatov
2013-08-18 20:29 ` Joseph S. Myers
2013-09-01 20:42 Dinar Temirbulatov
2013-09-01 20:43 Dinar Temirbulatov
2013-09-02 15:08 ` Joseph S. Myers
2013-09-03 17:31   ` Abhishek Deb
2013-09-05 12:56   ` Dinar Temirbulatov
2013-09-05 15:48     ` Joseph S. Myers
2013-09-05 17:09       ` Abhishek Deb
2013-09-11 19:25         ` Dinar Temirbulatov
2013-09-11 19:27         ` Dinar Temirbulatov
2013-09-11 20:40           ` Abhishek Deb
2013-09-13 17:14           ` Joseph S. Myers
2013-09-14  3:29             ` Dinar Temirbulatov
2013-09-18 17:16               ` Joseph S. Myers
2013-09-19  6:53                 ` Maxim Kuvyrkov
2013-09-19 16:29                   ` Joseph S. Myers

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=0E42B6C0C4628E48B8DF5D3F3C8FCA8898F1F8BF56@HQMAIL02.nvidia.com \
    --to=adeb@nvidia.com \
    --cc=dinar@kugelworks.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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