search for: __arm_neon__

...Xcode version to support really old iOS > devices, Apple?s armv6/armv7 selection was a compile-time switch (supported > using fat binaries). ?I think the arch can be detected based on on > preprocessor defines, though I can?t find the specific settings offhand. You can use e.g. the define __ARM_NEON__ - it is defined in apple toolchains when targeting both armv7 and arm64. Likewise, when the compiler is building code for armv7 it will use neon instructions in normal C codepaths as well (if it finds it useful). So the only even theoretical use for runtime detection on iOS would be trying to...

...ng to port the Neon > to ARM64. > On that function, saturate_32bit_to_16bit(), I noticed the ifdef's are > wrong. > The first version is for normal arm 32 bit arm and should be used for > arm32 and thumb2 but not thumb1. > The second version is 32 bit neon and should be #ifdef __ARM_NEON__ > I've done a third version which is 64 bit neon. I'm working off an > android version which is rc2 so I'll need to integrate, but here it is: > > #if defined(__aarch64__) > static inline int32_t saturate_32bit_to_16bit(int32_t a) { > int32_t ret; > asm volatile (...

Hi all, I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC preprocess.lo CC jitter.lo CC mdf.lo CC fftwrap.lo CC

...t joined because I'm needing to port the Neon to ARM64. On that function, saturate_32bit_to_16bit(), I noticed the ifdef's are wrong. The first version is for normal arm 32 bit arm and should be used for arm32 and thumb2 but not thumb1. The second version is 32 bit neon and should be #ifdef __ARM_NEON__ I've done a third version which is 64 bit neon. I'm working off an android version which is rc2 so I'll need to integrate, but here it is: #if defined(__aarch64__) static inline int32_t saturate_32bit_to_16bit(int32_t a) { int32_t ret; asm volatile ("sqxtn h0, %s[a]\n"...

...> to ARM64. >> On that function, saturate_32bit_to_16bit(), I noticed the ifdef's are >> wrong. >> The first version is for normal arm 32 bit arm and should be used for >> arm32 and thumb2 but not thumb1. >> The second version is 32 bit neon and should be #ifdef __ARM_NEON__ >> I've done a third version which is 64 bit neon. I'm working off an >> android version which is rc2 so I'll need to integrate, but here it is: >> >> #if defined(__aarch64__) >> static inline int32_t saturate_32bit_to_16bit(int32_t a) { >> int32_t...

This adds run-time CPU detection for iOS devices. I found this page useful for CPU support and models: http://iossupportmatrix.com/ The patch could be simplified to just set the OPUS_CPU_ARM_NEON flag if you think it's unlikely that anyone would be running on the really old devices that don't support NEON. Tom -------------- next part -------------- An HTML attachment was scrubbed...

...oinitializer, align 8 The difference between uint8x8 and int8x8 is done via 'nsw' (which, unless it's really generating a trap value, it's a misleading tag), but there's nothing that will flag this type as poly8x8. When I try to compile this with Clang: === comp.c === #define __ARM_NEON__ #include <arm_neon.h> int8x8_t i8d; uint8x8_t u8d; poly8x8_t p8d; void vceq() { u8d = vceq_s8(i8d, i8d); u8d = vceq_p8(p8d, p8d); } === end === It generates exactly the same instruction for both calls: $ clang -ccc-host-triple armv7a-none-eabi -ccc-gcc-name arm-none-eabi-gcc...

On Sep 27, 2010, at 2:58 AM, Renato Golin wrote: > On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: >> But regardless they are still structures, right? What does it mean for them to map onto other types? Is the parser supposed to treat them as if they _were_ those other types? If so, I think you need to define a type system for those fundamental vector

...m/lib/xor-neon.c~crypto-arm-xor-add-missing-module_description-macro +++ a/arch/arm/lib/xor-neon.c @@ -8,6 +8,7 @@ #include <linux/raid/xor.h> #include <linux/module.h> +MODULE_DESCRIPTION("NEON accelerated XOR implementation"); MODULE_LICENSE("GPL"); #ifndef __ARM_NEON__ _ Patches currently in -mm which might be from quic_jjohnson at quicinc.com are

...ce between uint8x8 and int8x8 is done via 'nsw' (which, > unless it's really generating a trap value, it's a misleading tag), > but there's nothing that will flag this type as poly8x8. > > When I try to compile this with Clang: > > === comp.c === > #define __ARM_NEON__ > #include <arm_neon.h> > > int8x8_t i8d; > uint8x8_t u8d; > poly8x8_t p8d; > > void vceq() { > u8d = vceq_s8(i8d, i8d); > u8d = vceq_p8(p8d, p8d); > } > === end === > > It generates exactly the same instruction for both calls: > > $...

On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: > But regardless they are still structures, right?  What does it mean for them to map onto other types?  Is the parser supposed to treat them as if they _were_ those other types?  If so, I think you need to define a type system for those fundamental vector types.  I had read those statements to say something about the

...m/lib/xor-neon.c~crypto-arm-xor-add-missing-module_description-macro +++ a/arch/arm/lib/xor-neon.c @@ -8,6 +8,7 @@ #include <linux/raid/xor.h> #include <linux/module.h> +MODULE_DESCRIPTION("NEON accelerated XOR implementation"); MODULE_LICENSE("GPL"); #ifndef __ARM_NEON__ _ Patches currently in -mm which might be from quic_jjohnson at quicinc.com are lib-test_objpool-add-missing-module_description-macro.patch crypto-arm-xor-add-missing-module_description-macro.patch x86-mm-add-testmmiotrace-module_description.patch cpufreq-powerpc-add-missing-module_description-ma...