Displaying 10 results from an estimated 10 matches for "__arm_neon__".
2015 Jan 08
1
[PATCH] Add ARM cpu detection for iDevices
...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...
2016 Jul 30
2
Cannot compile speexdsp 1.2rc3 on ARM64
...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 (...
2015 Mar 28
4
Cannot compile speexdsp 1.2rc3 on ARM64
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
2016 Apr 19
0
Cannot compile speexdsp 1.2rc3 on ARM64
...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"...
2016 Aug 09
0
Cannot compile speexdsp 1.2rc3 on ARM64
...> 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...
2015 Jan 08
2
[PATCH] Add ARM cpu detection for iDevices
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...
2010 Sep 27
2
[LLVMdev] Vectors in structures
...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...
2010 Sep 27
0
[LLVMdev] Vectors in structures
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
2010 Sep 27
0
[LLVMdev] Vectors in structures
...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:
>
> $...
2010 Sep 27
2
[LLVMdev] Vectors in structures
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