similar to: [PATCH 1/2] Add separate labels for the start of public functions

I?m trying to build Opus (git master) for iOS, and it doesn?t build unless I disable the ARM assembly. It looks like the problem is that Apple?s assembler doesn?t support all the assembler directives that the GNU assembler does. I suspect this is a combination of the fact that Apple platforms are Mach-O rather than Elf, and just the fact that Apple?s assembler is extremely divergent from the

This allows building the arm assembly for iOS. This checks for the __APPLE__ preprocessor built-in define to determine whether this extra handling should be enabled. --- Makefile.am | 2 +- celt/arm/arm2gnu.pl | 23 +++++++++++++++++------ configure.ac | 8 ++++++++ 3 files changed, 26 insertions(+), 7 deletions(-) diff --git a/Makefile.am b/Makefile.am index c39d803..e76b204

On Fri, 7 Feb 2014, Timothy B. Terriberry wrote: > Martin Storsjo wrote: >> This is required in order to build using the built-in assembler >> in clang. > > These patches break the gcc build (with "Error: bad instruction"). Ah, right, sorry about that. > Documentation I've seen is contradictory on which order ({cond}{size} or > {size}{cond}) is correct.

Martin Storsjo wrote: > + [AC_MSG_RESULT([yes]); ARM2GNU_PARAMS="-apple"], I'd prefer --apple instead of -apple, but otherwise these patches both look good to me. Does Apple have equivalent machinery to any of the pieces you disabled? Those were: - object size calculations so debuggers can tell what function they're in - architecture flags so an

On 03/10/2014 06:56 PM, Ralph Giles wrote: > On 2014-03-10 2:47 PM, Jonathan Lennox wrote: >> If I add --disable-asm to the build, it builds correctly. >> >> Does anyone have experience with Apple assembler directives to know >> what?s the best way to fix this? I assume the Perl script to generate >> the assembler file is going to need to be modified somehow. >

On Sat, 8 Feb 2014, Martin Storsjo wrote: > This is required in order to build using the built-in assembler > in clang. > --- > I squashed the two changes since it would break the normal gcc > build otherwise. > --- > celt/arm/arm2gnu.pl | 2 ++ > celt/arm/celt_pitch_xcorr_arm.s | 18 +++++++++--------- > 2 files changed, 11 insertions(+), 9 deletions(-)

Hi all, This is Linfeng Zhang from Google. I'll work on ARM NEON optimization in the next few months. I'm submitting 2 patches in the following couple of emails, which have the new created celt_fir_neon(). I revised celt_fir_c() to not pass in argument "mem" in Patch 1. If there are concerns to this change, please let me know. Many thanks to your comments. Linfeng Zhang

Linfeng Zhang wrote: > +#ifdef SMALL_FOOTPRINT > + for (i=0;i<N-7;i+=8) > + { > [snip over 80 lines of complicated NEON intrinsics code] > + } > +#else So, one of the points of SMALL_FOOTPRINT is to reduce the code size on targets where this matters (even if it means running slower), but this is an awful lot of code. I think it makes much more sense to expose the

Unfortunately I don't have a setup that lets me easily profile ARM code, so I really can't tell which method is faster (though I suspect Mr. Zanelli's code is). Let me offer up another intrinsic version of the NEON xcorr_kernel that is almost identical to the SSE version, and more in line with Mr. Zanelli's code: static inline void xcorr_kernel_neon(const opus_val16 *x, const

Hi All, Regarding cycle measurements for ARM/NEON, ARM no longer provide cycle accurate simulators. The method we use is to to make measurements on hardware via the PMU unit on the core itself. Note that if your running under Linux you may be 'allowed' to access the PMU directly but can access via it system calls. Typically you will need to make a series of measurements and average them.

This is required in order to build using the built-in assembler in clang. --- celt/arm/celt_pitch_xcorr_arm.s | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/celt/arm/celt_pitch_xcorr_arm.s b/celt/arm/celt_pitch_xcorr_arm.s index 09917b1..3c4b950 100644 --- a/celt/arm/celt_pitch_xcorr_arm.s +++ b/celt/arm/celt_pitch_xcorr_arm.s @@ -309,7 +309,7 @@

On Wed, 19 Mar 2014, Timothy B. Terriberry wrote: > Does Apple have equivalent machinery to any of the pieces you disabled? > Those were: > - object size calculations so debuggers can tell what function they're in I'm not really aware of any equivalent directives that they'd support at least, and judging from the output from -S from their compiler, they don't include

This is required in order to build using the built-in assembler in clang. --- I squashed the two changes since it would break the normal gcc build otherwise. --- celt/arm/arm2gnu.pl | 2 ++ celt/arm/celt_pitch_xcorr_arm.s | 18 +++++++++--------- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/celt/arm/arm2gnu.pl b/celt/arm/arm2gnu.pl index eab42ef..5c24758 100755 ---

The attached patch cleans up Opus's x86 intrinsics configury. It: * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in

From: Jonathan Lennox <jonathan at vidyo.com> * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in floating-point mode, not

From: Jonathan Lennox <jonathan at vidyo.com> * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in floating-point mode, not

Martin Storsjo wrote: > This is required in order to build using the built-in assembler > in clang. These patches break the gcc build (with "Error: bad instruction"). Documentation I've seen is contradictory on which order ({cond}{size} or {size}{cond}) is correct. If clang really does require the latter, then the arm2gnu.pl translation script will need to be updated

On 2014-03-10 2:47 PM, Jonathan Lennox wrote: > If I add --disable-asm to the build, it builds correctly. > > Does anyone have experience with Apple assembler directives to know > what?s the best way to fix this? I assume the Perl script to generate > the assembler file is going to need to be modified somehow. Yep, https://git.xiph.org/?p=opus.git;a=blob;f=celt/arm/arm2gnu.pl

Hi JM, I have no doubt that Mr. Zanelli's NEON code is faster, since hand tuned assembly is bound to be faster than using intrinsics. However I notice that his code can also read past the y buffer. Cheers, --John On 6/6/2013 9:22 PM, Jean-Marc Valin wrote: > Hi John, > > Thanks for the two fixes. They're in git now. Your SSE version seems to > also be slightly faster than

Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch: