[PATCH, v3] ARM: Integrate Cortex-A15 optimized memcpy using NEON/VFP.

[Richard Earnshaw]

On 12/04/13 08:42, Schwarz, Konrad wrote:
>> -----Original Message-----
>> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
>> On Behalf Of Will Newton
>> Sent: Thursday, April 11, 2013 10:14 PM
>> To: Ramana Radhakrishnan
>> Cc: newlib@sourceware.org
>> Subject: Re: [PATCH, v3] ARM: Integrate Cortex-A15 optimized memcpy
>> using NEON/VFP.
>
> My apologies if this has all been answered before, but the floating-point
> units I am familiar with usually allow lazy context switching.
> A common operating system optimization is give threads a floating point
> context only after they actually start executing floating point operations.
> (The initial floating point instruction causes a trap; the OS can
> initializes the thread's floating point context before restarting
> the instruction.)
> Threads start off as integer (register) context only.
>
> Won't an implementation of a nominally non-floating point function
> such as memcpy break this optimization, and perhaps be harmful from
> a system standpoint?
>
> In bare-metal systems, the OS/Executive/whatever may not even have
> have floating point support and would be in for a rude surprise
> when they call memcpy().
>
> Konrad Schwarz
>
>
>

I would have thought these days, with hardware floating-point support 
required by the Linux HF ABI, that this wasn't likely to be a major 
issue.  The compiler will use FP insns freely as well whenever they are 
available, even for data moves.  If you're using memcpy enough for 
performance to be an issue, then you'd want to use the fastest sequence 
possible.  If you're not, then why would you care?

I see build options in the code for three variants: With Neon (and VFP), 
with VFP only and without either.  That means that a bare metal systems 
have the option of using an integer-only variant (as does anyone else if 
they are really worried about using FP registers within memcpy).

R.