similar to: [LLVMdev] arm neon intrinsics cross compile error on windows system

Hello, James Molly. Thank you for your advices. Now I aware that this is the problem of stdint.h. And, codesourcery toolchain also has stdint.h header file at same place of stdio.h Generally, Clang has "lib/clang/3.0/include" default search path. If I added codesourcery toolchain path for stdio.h with -I option, stdint.h has been loaded at the specified toolchain path first cuz

Hello, Anton Korobeynikov. I just built the llvm using ms visual studio 2010 and ran the compile command on windows default command console. additionally, I also specified include dir of arm codesourcery latest toolchain because of missing stdio.h and stdint.h . Thanks and best regards, Seung-yeon. 2011/11/23 Anton Korobeynikov <anton at korobeynikov.info> > Hello > > > In

Hello, I totally understood about this problem. codesourcery codebench arm eabi version uses newlibc. but, arm gnu/linux version uses glibc. hm.. actually there is no problem. it was my mistake as james told me. Thanks. 2011/11/24 Seung-yeon Choe <sychoe at gmail.com> > Hello, James Molly. > > Thank you for your advices. > > Now I aware that this is the problem of

Hi, Just to clarify, some header files are compiler specific. Stdint.h is one of them. The reason your Ubuntu stdint.h works is because, coincidentally, Clang's stdint.h uses the same layout and pre-processor built-ins as GCC. This is an implementation detail. Do not rely upon it. You should use Clang's stdint.h. Cheers, James From: Seung-yeon Choe [mailto:sychoe at gmail.com] Sent: 24

Hello > In file included from helloneon.c:4: > d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: > error: invalid vector element type 'int32_t' (aka 'long') This looks weird, why int32_t is long? Are you using cygwin somehow? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi, There is a little bit awkward thing. If I need to use the newlibc printf function regardless stdint.h is compiler specific implementation, I should remove or block newlibc's stdint.h and the others because as you know clang already stdint.h (glibc compatible??) header but it is not standard library full set, right? On the other hand, even if I want to use other toolchain's glibc

On 27 September 2010 18:19, Bob Wilson <bob.wilson at apple.com> wrote: > I'm not sure what you mean by this.  The llvm intrinsics and built-in vector operations use plain vectors regardless of the front-end.  The structures are only relevant for things like argument passing and copying -- you can't do anything else with them.  Can you post an example of the 5X IR code size that

Support for NEON intrinsics in clang is not complete. Poly types in general are known to be an issue, and the vceq_p8 in your example definitely needs an intrinisic. It should work with llvm-gcc. Can you clarify ARM's position on those structure types? It sounds like you are advocating that we get rid of them. The only reason we've been using them in llvm-gcc and clang is for

Created corresponding unit test, and the optimization is bit exact with C function. This optimization speeds up SILK encoder on NEON as following. Fixed-point: Complexity 0-5: 0% Complexity 6-7: 6% Complexity 8-9: 10% Complexity 10: 8% Got similar results on floating-point. --- silk/NSQ_del_dec.c | 6 +- silk/SigProc_FIX.h | 4

Used for celt_pitch_xcorr on aarch64, and celt_fir and celt_iir on both armv7 and aarch64. --- celt/arm/arm_celt_map.c | 17 +++++++++++++ celt/arm/celt_neon_intr.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++- celt/arm/pitch_arm.h | 31 +++++++++++++++++++++++- 3 files changed, 107 insertions(+), 2 deletions(-) diff --git a/celt/arm/arm_celt_map.c b/celt/arm/arm_celt_map.c index

Hi John, Thanks for the two fixes. They're in git now. Your SSE version seems to also be slightly faster than mine -- probably due the the partial sums. As for the NEON code, it would be good to compare the performance with the code Aur?lien Zanelli posted at http://darkosphere.fr/public/0002-Add-optimized-NEON-version-of-celt_fir-celt_iir-and-.patch Cheers, Jean-Marc On 06/06/2013 08:07

Hi JM, At line 221 in celt_lpc.c (the celt_iir function) I think you really want the RESTORE_STACK statement to be before the #endif instead of after it. Also, I couldn't help notice that your SSE code for xcorr_kernel reads more than "len" elements of "_x". I don't know if that's really a problem when running the codec, but a tool like valgrind will have a

From: Jyri Sarha <jsarha at ti.com> Use --enable-neon to force NEON optimization on. The auto detection should also work if your CFLAGS supports NEON. --- configure.ac | 32 +++++++++++++++++++++++++++++++- 1 files changed, 31 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 255c0b4..08d3d5f 100644 --- a/configure.ac +++ b/configure.ac @@ -89,6 +89,23 @@

I'm trying to do a standalone build of Opus and I get the following messages when compiling for android arm64 using clang:   CC       silk/fixed/arm/warped_autocorrelation_FIX_neon_intr.lo silk/fixed/arm/warped_autocorrelation_FIX_neon_intr.c:43:37: warning: incompatible pointer types assigning to 'const long *' from 'long long *' [-Wincompatible-pointer-types]    

Dear all I'd wonder why executable's debug information size is bigger than gcc dwarf debug info. When I compiled ARM hello world code with -g option, the arm based assembly and executable files are bigger than gcc results significiantly.(apx. 3x) (source file size was only 3KB) I think that both clang and gcc use same dwarf format ver2 for debugging. But I don't know why the clang

--- Makefile.am | 8 +++-- silk/NSQ.c | 37 ++++++++-------------- silk/NSQ.h | 70 +++++++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.c | 64 +++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.h | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++ silk/x86/NSQ_sse.c | 2 +- silk/x86/main_sse.h | 3 +- silk_headers.mk | 2 ++ silk_sources.mk

--- Makefile.am | 5 +-- silk/NSQ.c | 37 ++++++++-------------- silk/NSQ.h | 70 +++++++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.c | 64 +++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.h | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++ silk/x86/NSQ_sse.c | 2 +- silk/x86/main_sse.h | 3 +- silk_headers.mk | 2 ++ silk_sources.mk

Hi, I found some errors in the Clang/LLVM lowering of NEON instructions. There are three types of errors: 1. In Clang's arm_neon.h, the definition of vshl_u8 is wrong. According to ARM's document [1], the shift amount parameter is *always* signed, even for unsigned values, since a negative shift means right shift. I believe the header should be changed to conform to ARM's

On Tue, Sep 21, 2010 at 11:07 PM, Alasdair Grant <Alasdair.Grant at arm.com> wrote: > Bob Wilson writes: >> On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: >> > I was checking NEON instructions this week and the vector types seem >> > to be inside structures. If vector types are considered proper types >> > in LLVM, why pack them inside structures?

Bob Wilson writes: > On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: > > I was checking NEON instructions this week and the vector types seem > > to be inside structures. If vector types are considered proper types > > in LLVM, why pack them inside structures? > > Because that is what ARM has specified? They define the vector types > that are used with their NEON