public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
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

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