[opus] [PATCH] Add ARM cpu detection for iDevices

[Tom Hughes]

Yeah, I'm not particularly interested in supporting older devices; I just
wanted to ensure all the optimized NEON routines were used. I missed the
PRESUME_NEON macro when real-time cpu detection is disabled
(celt/arm/pitch_arm.h) in the fixed point section:

#  if !defined(OPUS_HAVE_RTCD)
#   define OVERRIDE_PITCH_XCORR (1)
#   define celt_pitch_xcorr(_x, _y, xcorr, len, max_pitch, arch) \
  ((void)(arch),PRESUME_NEON(celt_pitch_xcorr)(_x, _y, xcorr, len,
max_pitch))
#  endif

It looks like in both the fixed point and floating point case on iOS with
real-time cpu detection disabled celt_pitch_xcorr_float_neon will be used,
so there's probably no reason for this patch.






On Thu, Jan 8, 2015 at 12:48 PM, Martin Storsjö <martin at martin.st> wrote:

> On Thu, 8 Jan 2015, Jonathan Lennox wrote:
>
>  Every armv7 (and armv8) iOS device has supported Neon, and Xcode support
>> for
>> armv6 was dropped with Xcode 4.5.
>>
>> Even if you’re compiling with an old 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 include NEON instruction codepaths in armv6 slices, but there's
> little reason for that, and you can't probably even submit such binaries to
> appstore any longer even if you'd have an old xcode version around.
>
> Thus, I wholeheartedly agree that there is no point in runtime detection
> for this on iOS - checking the __ARM_NEON__ define at compile time is
> enough.
>
> // Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20150108/90fb0b46/attachment.htm