From: Will Newton <will.newton@linaro.org>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: libc-ports@sourceware.org, Patch Tracking <patches@linaro.org>
Subject: Re: [PATCH v2] ARM: Add Cortex-A15 optimized NEON and VFP memcpy routines, with IFUNC.
Date: Mon, 22 Apr 2013 08:32:00 -0000 [thread overview]
Message-ID: <CANu=DmiTJM7-RzHFjwuhZ=d+s=_iWAdVVmrwLk0kEN70BNmv2w@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1304192138380.27838@digraph.polyomino.org.uk>
On 19 April 2013 22:47, Joseph S. Myers <joseph@codesourcery.com> wrote:
Hi Joseph,
> On Tue, 16 Apr 2013, Will Newton wrote:
>
>> Add a high performance memcpy routine optimized for Cortex-A15 with
>> variants for use in the presence of NEON and VFP hardware selected
>> at runtime using indirect function support.
>
> The functions __aeabi_memcpy, __aeabi_memcpy4 and __aeabi_memcpy8,
> currently implemented to call memcpy, have their ABI defined to clobber
> only the core registers permitted to be clobbered by AAPCS, and not the
> normally call-clobbered VFP/NEON registers.
>
> This patch would cause those functions to start clobbering some VFP/NEON
> registers. So you need to do something to avoid that, whether making the
> __aeabi_* functions save and restore registers in the affected case,
> making the new functions do so or some other approach such as making
> __aeabi_* use a variant of the code with an extra save/restore.
>
> As I understand the code, memcpy within ld.so itself will always be a
> version using the core registers only, so you shouldn't have the extra
> issue of needing to avoid corrupting such registers when used for argument
> passing in the VFP ABI variant. Though if you were to support building a
> glibc version that requires VFP/NEON, where the new code is used
> unconditionally rather than just through IFUNC - and such a glibc is a
> perfectly reasonable thing to build, after all if you are building for the
> VFP ABI then you may as well assume at least VFP to be present everywhere
> - then you would need to deal with that issue. (Cf.
> <http://sourceware.org/ml/libc-ports/2012-04/msg00087.html>.)
I suspect adding in extra saving/restoring would be a significant
performance overhead, particularly for small copies. Would it make
sense just to make __aeabi_memcpy call the fallback arm routine? That
would mean no performance improvement for __aeabi_memcpy calls but no
performance degradation for the explicit memcpy case.
--
Will Newton
Toolchain Working Group, Linaro
prev parent reply other threads:[~2013-04-22 8:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 9:25 Will Newton
2013-04-17 15:40 ` Richard Henderson
2013-04-17 15:53 ` Will Newton
2013-04-18 7:42 ` Richard Henderson
2013-04-18 7:47 ` Siddhesh Poyarekar
2013-04-18 7:54 ` Will Newton
2013-04-18 8:26 ` Siddhesh Poyarekar
2013-04-18 8:38 ` Will Newton
2013-04-18 17:58 ` Siddhesh Poyarekar
2013-04-22 8:27 ` Will Newton
2013-04-17 17:51 ` Carlos O'Donell
2013-04-18 8:01 ` Will Newton
2013-04-19 21:47 ` Joseph S. Myers
2013-04-22 8:32 ` Will Newton [this message]
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='CANu=DmiTJM7-RzHFjwuhZ=d+s=_iWAdVVmrwLk0kEN70BNmv2w@mail.gmail.com' \
--to=will.newton@linaro.org \
--cc=joseph@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=patches@linaro.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).