From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Will Newton <will.newton@linaro.org>
Cc: <libc-ports@sourceware.org>, <patches@linaro.org>
Subject: Re: [PATCH v2] ARM: Add Cortex-A15 optimized NEON and VFP memcpy routines, with IFUNC.
Date: Fri, 19 Apr 2013 21:47:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1304192138380.27838@digraph.polyomino.org.uk> (raw)
In-Reply-To: <516D18F0.4060009@linaro.org>
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>.)
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2013-04-19 21:47 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 [this message]
2013-04-22 8:32 ` Will Newton
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=Pine.LNX.4.64.1304192138380.27838@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=patches@linaro.org \
--cc=will.newton@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).