This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH, v5] ARM: Add Cortex-A15 optimized NEON and VFP memcpy routines, with IFUNC.
- From: Will Newton <will dot newton at linaro dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-ports at sourceware dot org, Patch Tracking <patches at linaro dot org>
- Date: Wed, 1 May 2013 19:43:10 +0100
- Subject: Re: [PATCH, v5] ARM: Add Cortex-A15 optimized NEON and VFP memcpy routines, with IFUNC.
- References: <517FF73E dot 5020509 at linaro dot org> <20130430171818 dot 697972C08A at topped-with-meat dot com> <CANu=DmhgUNKBos95su4qaeMRwWWij_Ss3_GhXjJmJChcMjFruA at mail dot gmail dot com> <20130501170134 dot 265AC2C096 at topped-with-meat dot com>
On 1 May 2013 18:01, Roland McGrath <roland@hack.frob.com> wrote:
>> > If __SOFTFP__ is predefined by the compiler, then the compiler is presuming
>> > VFP support anyway. So you can make this:
>> >
>> > #ifdef __SOFTFP__
>> > ldr r1, .Lmemcpy_arm
>> > tst r0, #HWCAP_ARM_VFP
>> > ldrne r1, .Lmemcpy_vfp
>> > #else
>> > ldr r1, .Lmemcpy_vfp
>> > #endif
>> >
>> > (and also conditionalize .Lmemcpy_arm, below).
>>
>> I'm not sure I follow the logic here, could you elaborate?
>
> I dropped a "not" in my first sentence, which might have been confusing.
> The compiler predefines __SOFTFP__ unless it's presuming VFP support. If
> __SOFTFP__ is not defined, then the compiler is already generating code
> that effectively presumes HWCAP_ARM_VFP will be set, so you might as well
> just elide any code testing it at runtime and statically do whatever you
> would do if HWCAP_ARM_VFP were set at runtime.
Ok, that makes sense. I'll make that change.
--
Will Newton
Toolchain Working Group, Linaro