From: James Greenhalgh <james.greenhalgh@arm.com>
To: Steve Ellcey <sellcey@cavium.com>
Cc: Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
gcc-patches <gcc-patches@gcc.gnu.org>, nd <nd@arm.com>,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
Marcus Shawcroft <Marcus.Shawcroft@arm.com>
Subject: Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64
Date: Tue, 21 Nov 2017 17:36:00 -0000 [thread overview]
Message-ID: <20171121173517.GA18058@arm.com> (raw)
In-Reply-To: <1511205735.16234.10.camel@cavium.com>
On Mon, Nov 20, 2017 at 07:22:15PM +0000, Steve Ellcey wrote:
> On Mon, 2017-11-20 at 18:27 +0000, James Greenhalgh wrote:
> >
> > If you have the time, would you mind giving me a quick run-down of what
> > design decisions went in to this patch, and why they are the right thing
> > to do? Sorry to offload that, but it will be the most efficient route
> > to a review.
>
> The main design decision was to use the existing IFUNC infrastructure
> that is used on ARM32 to enable atomic instructions that were added
> with armv7-a, on i386 to enable instructions added with i586, and on
> x86_64 to enable instructions added with cx16.
>
> The basic idea for all these is to allow users who create programs that
> use the atomic_* functions to use new instructions on machines that
> support them while also working on older machines that do not support
> them and to not have to create two separate executables.
>
> Some atomic_* functions get inlined into programs, and those will
> either use or not use LSE instructions based on the compiler arguments
> used during compilations.  If you want your program to work on all
> machines you have to not compile for LSE intructions.  But other
> functions (or all functions if -fno-inline-atomics is used) will call
> the libatomic library.  Currently those functions do not use LSE
> instructions but with this patch we can use the IFUNC infrastructure to
> check for LSE support and use LSE in libatomic on machines where it is
> supported or not use it on machines where it is not supported.
>
> As an example of what this change does, __atomic_compare_exchange_8 will
> turn into a call to libat_compare_exchange_8_i1 on a machine that supports
> LSE:
>
> 0000000000000000 <libat_compare_exchange_8_i1>:
> Â Â Â 0: f9400023Â ldr x3, [x1]
> Â Â Â 4: aa0303e4Â mov x4, x3
> Â Â Â 8: c8e4fc02Â casal x4, x2, [x0]
>    c: eb03009f cmp x4, x3
> Â 10: 1a9f17e0Â cset w0, eq
> Â 14: 35000040Â cbnz w0, 1c <libat_compare_exchange_8_i1+0x1c>
> Â 18: f9000024Â str x4, [x1]
> Â 1c: d65f03c0Â ret
>
> But call libat_compare_exchange_8 on a machine without LSE:
>
> 0000000000000000 <libat_compare_exchange_8>:
> Â Â Â 0: f9400023Â ldr x3, [x1]
> Â Â Â 4: c85ffc04Â ldaxr x4, [x0]
>    8: eb03009f cmp x4, x3
> Â Â Â c: 54000061Â b.ne 18 <libat_compare_exchange_8+0x18>
> Â 10: c805fc02Â stlxr w5, x2, [x0]
> Â 14: 35ffff85Â cbnz w5, 4 <libat_compare_exchange_8+0x4>
> Â 18: 1a9f17e0Â cset w0, eq
> Â 1c: 34000040Â cbz w0, 24 <libat_compare_exchange_8+0x24>
> Â 20: d65f03c0Â ret
> Â 24: f9000024Â str x4, [x1]
> Â 28: d65f03c0Â ret
>  2c: d503201f nop
Thanks for the detailed explanation. I understood this, and my opinion is
that the AArch64 parts of this patch are OK (and I don't know who needs to
Ack the small generic changes you require).
Let's give Richard/Marcus 48 hours to object while we wait for an OK on the
generic bits, and then OK for AArch64.
Thanks,
James
Reviewed-By: James Greenhalgh <james.greenhalgh@arm.com>
next prev parent reply other threads:[~2017-11-21 17:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 20:44 Steve Ellcey
2017-08-07 20:46 ` Steve Ellcey
2017-08-25 4:56 ` Steve Ellcey
2017-08-25 16:43 ` Szabolcs Nagy
2017-08-28 18:40 ` Steve Ellcey
2017-08-29 11:42 ` Szabolcs Nagy
2017-08-30 18:39 ` Steve Ellcey
2017-08-31 18:55 ` Steve Ellcey
2017-09-27 20:35 ` Steve Ellcey
2017-09-28 11:31 ` Szabolcs Nagy
2017-09-29 20:29 ` Steve Ellcey
2017-10-02 14:38 ` Szabolcs Nagy
2017-10-03 18:57 ` Steve Ellcey
2017-10-24 18:17 ` Steve Ellcey
2017-11-20 18:27 ` Steve Ellcey
2017-11-20 18:29 ` James Greenhalgh
2017-11-20 19:50 ` Steve Ellcey
2017-11-21 17:36 ` James Greenhalgh [this message]
2017-11-29 8:09 ` Steve Ellcey
2017-12-05 0:51 ` Steve Ellcey
2017-12-07 9:56 ` James Greenhalgh
2017-12-07 15:58 ` Steve Ellcey
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=20171121173517.GA18058@arm.com \
--to=james.greenhalgh@arm.com \
--cc=Marcus.Shawcroft@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=nd@arm.com \
--cc=sellcey@cavium.com \
/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).