search for: rvct

...<bob.wilson at apple.com> wrote: > 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 compatibility for ARM's specifications and with ARM's RVCT compiler.  If ARM does not care about those things, I'd love to remove the struct wrappers from llvm. As Al said earlier, you definitely don't need the structures for compatibility with armcc. As far as the LLVM back-end is concerned, with or without structures, the instruction selection...

hi all, I can claim that our hotfoon service has run millions of mobile voip minutes using speex on mobile and desktops. it works! earlier you needed more powerful cpus (until the integer port), however now the cpus are much faster and the code complexity is much lower. my only regret is of not being able to write some demo apps for speex on win mob. I will surely deliver it in june to settle this

...(organized) in order to gather data and test cases (in a distributed way) about "on which platform speex run". After my post i received some email privately stating about custom ARM assembly enhancements that give 25% less cpu power, while others are providing suggestion to use the RVCT ARM compiler (http://www.arm.com/products/DevTools/RVCT.html) . Still, i am not able to answer my question and i am not sure whether it's best to pay AMR royalties or invest and risk on free speex codec. I would suggest to : - create sample application doing benchmarking for - playing sp...

...;bob.wilson at apple.com> wrote: >> 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 compatibility for ARM's specifications and with ARM's RVCT compiler. If ARM does not care about those things, I'd love to remove the struct wrappers from llvm. > > As Al said earlier, you definitely don't need the structures for > compatibility with armcc. An implementation, such as in GCC, that does not use structures is compatible wit...

...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 compatibility for ARM's specifications and with ARM's RVCT compiler. If ARM does not care about those things, I'd love to remove the struct wrappers from llvm. On Sep 27, 2010, at 2:51 PM, Renato Golin wrote: > 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...

On 27 September 2010 23:45, Bob Wilson <bob.wilson at apple.com> wrote: > An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction.  GCC will accept any code written for RVCT, but not the other way around.  And, as Al pointed out, there are also compatibility issues with how you can initialize vectors.  (In fact, if you stick to the documented interfaces, the only way you can initialize a vector to an arbitrary value is by loading from memory.) Hi Bob, Can you clarify...

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

Hello Jim, Thank you for the response. I may be confused about the alignment rules here. I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in this case to mea...

...e work related to better utilization of those for other constructs. -Jim On Sep 5, 2012, at 4:25 PM, Peter Couperus <peter.couperus at st.com> wrote: > Hello Jim, > > Thank you for the response. I may be confused about the alignment rules here. > I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table > (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). > Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in this case...

...of those for other constructs. > > -Jim > > On Sep 5, 2012, at 4:25 PM, Peter Couperus<peter.couperus at st.com> wrote: > >> Hello Jim, >> >> Thank you for the response. I may be confused about the alignment rules here. >> I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table >> (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >> Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in t...

VLD1 expects a 64-bit aligned address unless the target explicitly days that unaligned loads are OK. For your situation, either the subtarget should set AllowsUnalignedMem to true (if that's accurate), or the load address should be made 64-bit aligned. -Jim On Sep 5, 2012, at 2:42 PM, Peter Couperus <peter.couperus at st.com> wrote: > Hello all, > > I am a first time writer

...of those for other constructs. > > -Jim > > On Sep 5, 2012, at 4:25 PM, Peter Couperus<peter.couperus at st.com> wrote: > >> Hello Jim, >> >> Thank you for the response. I may be confused about the alignment rules here. >> I had been looking at the ARM RVCT Assembler Guide, which seems to >> indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >> Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in...

Hello all, I am a first time writer here, but am a happy LLVM tinkerer. It is a pleasure to use :). We have come across some sub-optimal behavior when LLVM lowers loads for vectors with small integers, i.e. load <4 x i16>* %a, align 2, using a sequence of scalar loads rather than a single vld1 on armv7 linux with NEON. Looking at the code in svn, it appears the ARM backend is capable of

...2010, at 2:07 AM, Renato Golin wrote: > On 27 September 2010 23:45, Bob Wilson <bob.wilson at apple.com> wrote: >> An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction. GCC will accept any code written for RVCT, but not the other way around. And, as Al pointed out, there are also compatibility issues with how you can initialize vectors. (In fact, if you stick to the documented interfaces, the only way you can initialize a vector to an arbitrary value is by loading from memory.) > > Hi Bob, >...

...> -Jim >> >> On Sep 5, 2012, at 4:25 PM, Peter Couperus<peter.couperus at st.com> wrote: >> >>> Hello Jim, >>> >>> Thank you for the response. I may be confused about the alignment rules > here. >>> I had been looking at the ARM RVCT Assembler Guide, which seems to >>> indicate vld1.16 operates on 16-bit aligned data, unless I am > misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >>> Prior to the table, It does mention the accesses need to be "element" > aligned, where...

...> >> On Sep 5, 2012, at 4:25 PM, Peter Couperus<peter.couperus at st.com> wrote: >> >>> Hello Jim, >>> >>> Thank you for the response. I may be confused about the alignment >>> rules > here. >>> I had been looking at the ARM RVCT Assembler Guide, which seems to >>> indicate vld1.16 operates on 16-bit aligned data, unless I am > misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >>> Prior to the table, It does mention the accesses need to be "element" > aligned, where...

...neously > by using different complexity parameters. the testenc application mostly does that, so do speexenc/speexdec > - release binaries of the sample applications for Windows Mobile and > Symbian OS > - compiled with GCC > - for different cpu type > - compiled with RVCT > - for different cpu type How will binaries help you? I don't have access to most platforms Speex runs on and even if I did, some have dozens of incompatible ways you can compile software on them. I've posted some binaries generated by others before, but that's the best I can d...

...2, at 4:25 PM, Peter Couperus<peter.couperus at st.com> wrote: >>> >>>> Hello Jim, >>>> >>>> Thank you for the response. I may be confused about the alignment >>>> rules >> here. >>>> I had been looking at the ARM RVCT Assembler Guide, which seems to >>>> indicate vld1.16 operates on 16-bit aligned data, unless I am >> misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >>>> Prior to the table, It does mention the accesses need to be "element" >>...

...er.couperus at st.com> > wrote: > >>> > >>>> Hello Jim, > >>>> > >>>> Thank you for the response. I may be confused about the alignment > >>>> rules > >> here. > >>>> I had been looking at the ARM RVCT Assembler Guide, which seems to > >>>> indicate vld1.16 operates on 16-bit aligned data, unless I am > >> misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). > >>>> Prior to the table, It does mention the accesses need to be "element&...

Please ignore my previous mail and patch, there is a new version :). Patch changes are: - Use MAC16_16 macros instead of (sum += a*b) and unroll a loop by 2. It increase performance when using optimized macros (ex: ARMv5E). A possible side effect of loop unroll is that i don't check for odd length here. - Add NEON version of FIR filter and autocorr - Add a section in autoconf in order to