NDK and NEON on QSD8250

[Louise Cypher]

Hi

I need some high perfomance code to be run on QSD8250 (the one in nexus one).
So I'v changed architecture in build\toolchains\arm-eabi-4.4.0\setup.mk to be arm7 not arm5 and tried to compile some realy simple stuff:

-- file <apps/MXEngine/project/jni/main.cpp>
#include <arm_neon.h>

extern void CrashTest(float32_t *a, float32_t *b, float32_t *o);

void CrashTest(float32_t *a, float32_t *b, float32_t *o)
{
 float32x4_t ta, tb, tc;

 ta = vld1q_dup_f32(a);
 tb = vld1q_dup_f32(b);
 tc = vmulq_f32(ta, tb);

 vst1q_lane_f32(o, tc, 0);
 return;
}
-- eof

compile command line:

build\prebuilt\windows\arm-eabi-4.4.0\bin\arm-eabi-g++ -Ibuild/platforms/android-5/arch-arm/usr/include -D__ARM_ARCH_7__ -march=armv7 -mfloat-abi=softfp -mfpu=neon -fno-exceptions -fno-rtti -mthumb -Iapps/MXEngine/project/jni -DANDROID -Werror -DANDROID_NDK -DNDEBUG -c -MMD -MP -MF out/apps/MXEngine/armeabi/objs/MXEngine/main.o.d.tmp apps/MXEngine/project/jni/main.cpp -o out/apps/MXEngine/armeabi/objs/MXEngine/main.o

and I get:

apps/MXEngine/project/jni/main.cpp:23: internal compiler error: in write_builtin_type, at cp/mangle.c:1855
Please submit a full bug report,

is there any trick to get it to work - some specific compiler options needs to be enabled ? I'v experimented a little and the compiler ALWAYS crashes no matter what compilation flags I pass :/
(I'm working with cygwin on win7 x64 if that matters)

Is there someone who actually uses NEON opcodes to do the heavy stuff (like on iPhone / iPad) ?


--
Code it black!

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[mic _]

Iirc I got some errors like that one with certain combinations of NEON instructions and operands, even when they conformed to the documentation from ARM. I don't know which is correct - gcc or the documentation. It's certainly a very poor error message in any case.

/Michael

[Louise Cypher]

but this is just load of float elements (with duplication), multiplication and store ???
Did you actualy ben able to compile SOME neon based code ?
What are your compilation flags ?

--

[mic _]

>Did you actualy ben able to compile SOME neon based code ?

Yeah, I did get some NEON code to compile. I was writing the NEON stuff in assembly though, so I haven't tried any of the C intrinsics.

>What are your compilation flags ?

The code and makefiles are all on my work computer, so I can't check them until monday.


/Michael

[Mark Rawls]

You can try these flags:
  -march=armv7-a -mfpu=neon -mfloat-abi=softfp 

I haven't tried the functions you are using, but note that if you write assembly with a neon quad-word multiply, the assembler will segfault in my experience.  It can handle some neon instructions, but some always cause a segfault for me.  If you really have to use these, the only solution I have found is to embed the machine code yourself, in a .S assembly file (the inline assembler has been flaky for me).

-Mark

[Louise Cypher]

even the simplest one wont compile

#include <arm_neon.h>

void CrashTest(float32_t *a, float32_t *b, float32_t *o)
{
 float32x4_t ta, tb, tc;

 ta = vld1q_f32(a);
 tb = vld1q_f32(b);
 tc = vmulq_f32(ta, tb);

 vst1q_f32(o, tc);
 return;
}

:/

If someone have some neon code that compiles please post (to test my sanity ;)  ... or mark me what I'm doing wrong here that the compiler crashes .... i understand that compiler may have poor support for neon ... but not THAT poor ;)
I could always go to assembly ... but I hope that this is not the only solution to have working neon enabled functions in code ...

[Louise Cypher]

-march=armv7-a -mfpu=neon -mfloat-abi=softfp

crashes nicelly to ...
so probably I'm doomed to assembly ... :/

BTW ... this one crashes too ... so this is not a qword only flaw

void CrashTest(float32_t *a, float32_t *b, float32_t *o)

{
 float32x2_t ta, tb, tc;

 ta = vld1_f32(a);
 tb = vld1_f32(b);
 tc = vmul_f32(ta, tb);

 vst1_f32(o, tc);
 return;

[Eong]

Hi,
I just want to ask, if your phone will use the lib from the areabiv7-
a directory in your apk? My milestone will still use the armv5 one.

On 5月14日, 下午10时35分, Louise Cypher <szatan.i....@gmail.com> wrote:
>  -march=armv7-a -mfpu=neon -mfloat-abi=softfp
>
> crashes nicelly to ...
> so probably I'm doomed to assembly ... :/
>
> BTW ... this one crashes too ... so this is not a qword only flaw
>
> void CrashTest(float32_t *a, float32_t *b, float32_t *o)
> {
>  float32x2_t ta, tb, tc;
>
>  ta = vld1_f32(a);
>  tb = vld1_f32(b);
>  tc = vmul_f32(ta, tb);
>
>  vst1_f32(o, tc);
>  return;
>
> }
>
> On 14 May 2010 16:28, Mark Rawls <mark.ra...@gmail.com> wrote:
>
>
>
> > You can try these flags:
> >   -march=armv7-a -mfpu=neon -mfloat-abi=softfp
>
> > I haven't tried the functions you are using, but note that if you write
> > assembly with a neon quad-word multiply, the assembler will segfault in my
> > experience.  It can handle some neon instructions, but some always cause a
> > segfault for me.  If you really have to use these, the only solution I have
> > found is to embed the machine code yourself, in a .S assembly file (the
> > inline assembler has been flaky for me).
>
> > -Mark
>

> > On Fri, May 14, 2010 at 10:22 AM, Louise Cypher <szatan.i....@gmail.com>wrote:
>
> >> but this is just load of float elements (with duplication), multiplication
> >> and store ???
> >> Did you actualy ben able to compile SOME neon based code ?
> >> What are your compilation flags ?
>

> >> On 14 May 2010 16:03, mic _ <micol...@gmail.com> wrote:
>
> >>> Iirc I got some errors like that one with certain combinations of NEON
> >>> instructions and operands, even when they conformed to the documentation
> >>> from ARM. I don't know which is correct - gcc or the documentation. It's
> >>> certainly a very poor error message in any case.
>
> >>> /Michael
>

> >>> On Fri, May 14, 2010 at 3:42 PM, Louise Cypher <szatan.i....@gmail.com>wrote:
>
> >>>>  Hi
>
> >>>> I need some high perfomance code to be run on QSD8250 (the one in nexus
> >>>> one).

> >>>> So I'v changed architecture in build\toolchains\arm-eabi-4.4.0\setup.mkto be arm7 not arm5 and tried to compile some realy simple stuff:

> >>>> android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>
> >>>> .

> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/android-ndk?hl=en.
>
> >>>  --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "android-ndk" group.
> >>> To post to this group, send email to andro...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/android-ndk?hl=en.
>
> >> --
> >> --
> >> Code it black!
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "android-ndk" group.
> >> To post to this group, send email to andro...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/android-ndk?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/android-ndk?hl=en.
>
> --
> --
> Code it black!
>
> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/android-ndk?hl=en.

[David Turner]

Can you try with the toolchain binaries that are in r4, I believe they would not crash. If this is still the case, I'll file a bug internally.

[Louise Cypher]

I'm using plain armeabi as so dir for now ... our app target specific client needs, (and will run on nexus one only (at least for now)) so this is not a big problem to use neon and cortex8 instructions within ours *.so)

[Brian]

I'm still seeing segmentation faults in the r4 (Cygwin) binaries,
either when assembling .s files directly or compiling with -mvectorize-
with-neon-quad.

On May 23, 3:19 pm, David Turner <di...@android.com> wrote:
> Can you try with the toolchain binaries that are in r4, I believe they would
> not crash. If this is still the case, I'll file a bug internally.
>

[Louise Cypher]

there is a simple solution for this :)
just get r4 sources from git repo and compile them using cygwin ... then all related neon segfaults are gone.

I do not know what is wrong with prebuilt windows ndk binaries, but they all (both from n3 and n4) segfault on neon opcodes/intrinsics (the mac and linux versions run just fine)

--
--
Code it black!

[David Turner]

On Mon, May 24, 2010 at 1:42 PM, Louise Cypher <szatan...@gmail.com> wrote:

there is a simple solution for this :)
just get r4 sources from git repo and compile them using cygwin ... then all related neon segfaults are gone.

I don't understand this. The r4 toolchain was built from the git repo :-( Are you claiming that rebuilding them on your machine generates binaries that don't segfault on your Cygwin install ?

[serge]

On May 25, 12:50 am, David Turner <di...@android.com> wrote:

> On Mon, May 24, 2010 at 1:42 PM, Louise Cypher <szatan.i....@gmail.com>wrote:
>
> > there is a simple solution for this :)
> > just get r4 sources from git repo and compile them using cygwin ... then
> > all related neon segfaults are gone.
>
> I don't understand this. The r4 toolchain was built from the git repo :-(
> Are you claiming that rebuilding them on your machine generates binaries
> that don't segfault on your Cygwin install ?
>
>
>
> > I do not know what is wrong with prebuilt windows ndk binaries, but they
> > all (both from n3 and n4) segfault on neon opcodes/intrinsics (the mac and
> > linux versions run just fine)
>
> > On 24 May 2010 20:26, Brian <mem...@gmail.com> wrote:
>
> >> I'm still seeing segmentation faults in the r4 (Cygwin) binaries,
> >> either when assembling .s files directly or compiling with -mvectorize-
> >> with-neon-quad.
>
> >> On May 23, 3:19 pm, David Turner <di...@android.com> wrote:
> >> > Can you try with the toolchain binaries that are in r4, I believe they
> >> would
> >> > not crash. If this is still the case, I'll file a bug internally.
>

The bug still present in r4b

[serge]

On May 25, 12:50 am, David Turner <di...@android.com> wrote:

> On Mon, May 24, 2010 at 1:42 PM, Louise Cypher <szatan.i....@gmail.com>wrote:
>
> > there is a simple solution for this :)
> > just get r4 sources from git repo and compile them using cygwin ... then
> > all related neon segfaults are gone.
>
> I don't understand this. The r4 toolchain was built from the git repo :-(
> Are you claiming that rebuilding them on your machine generates binaries
> that don't segfault on your Cygwin install ?
>
>
>
> > I do not know what is wrong with prebuilt windows ndk binaries, but they
> > all (both from n3 and n4) segfault on neon opcodes/intrinsics (the mac and
> > linux versions run just fine)
>
> > On 24 May 2010 20:26, Brian <mem...@gmail.com> wrote:
>
> >> I'm still seeing segmentation faults in the r4 (Cygwin) binaries,
> >> either when assembling .s files directly or compiling with -mvectorize-
> >> with-neon-quad.
>
> >> On May 23, 3:19 pm, David Turner <di...@android.com> wrote:
> >> > Can you try with the toolchain binaries that are in r4, I believe they
> >> would
> >> > not crash. If this is still the case, I'll file a bug internally.
>

Bug still persists in r4b :(

[Dave Cope]

I am also seeing this problem with the r4b toolchain on Windows and I
know other people running into the same problem as well. I was
wondering if anyone from Google has verified this problem, and if so
is there a fix planned for the next NDK release?

Rebuilding the tools from the git repository is not an ideal solution
for various reasons.

Thanks,
Dave

On Jul 14, 2:35 am, serge <serg...@gmail.com> wrote:
> On May 25, 12:50 am, David Turner <di...@android.com> wrote:
>
>
>
> > On Mon, May 24, 2010 at 1:42 PM, Louise Cypher <szatan.i....@gmail.com>wrote:
>
> > > there is a simple solution for this :)
> > > just get r4 sources from git repo and compile them using cygwin ... then

> > > all relatedneonsegfaults are gone.

>
> > I don't understand this. The r4 toolchain was built from the git repo :-(
> > Are you claiming that rebuilding them on your machine generates binaries
> > that don't segfault on your Cygwin install ?
>
> > > I do not know what is wrong with prebuilt windows ndk binaries, but they

> > > all (both from n3 and n4) segfault onneonopcodes/intrinsics (the mac and

[mingw.android]

I tested both versions of CrashTest with my latest windows r4b
toolchain in a msys environment at -O2 and had no ICE.

objdump output for the first version is:

Disassembly of section .text.CrashTest:

00000000 <CrashTest>:
}

__extension__ static __inline float32x4_t __attribute__
((__always_inline__))
vld1q_dup_f32 (const float32_t * __a)
{
return (float32x4_t)__builtin_neon_vld1_dupv4sf (__a);
0: f9e0 0caf vld1.32 {d16[]-d17[]}, [r0]
}

__extension__ static __inline float32x4_t __attribute__
((__always_inline__))
vmulq_f32 (float32x4_t __a, float32x4_t __b)
{
return (float32x4_t)__builtin_neon_vmulv4sf (__a, __b, 3);
4: f9e1 2caf vld1.32 {d18[]-d19[]}, [r1]
8: ff40 0df2 vmul.f32 q8, q8, q9
}

__extension__ static __inline void __attribute__ ((__always_inline__))
vst1q_lane_f32 (float32_t * __a, float32x4_t __b, const int __c)
{
__builtin_neon_vst1_lanev4sf (__a, __b, __c);
c: f9c2 080f vst1.32 {d16[0]}, [r2]

tb = vld1q_dup_f32(b);
tc = vmulq_f32(ta, tb);

vst1q_lane_f32(o, tc, 0);
return;
}

10: 4770 bx lr
12: bf00 nop

Which looks ok to me. You can get my native windows ndk at:

http://mingw-and-ndk.googlecode.com/files/android-ndk-r4b-prebuilt-20100725-windows.tar.bz2

I would welcome more testing.

Cheers.

[matros...@gmail.com]

It might be off topic, but you won't get much more performance on the Nexus One anyway due to the lack of L2 cache on the first-gen SnapDragon.

NEON's overall performance depends heavily on L2 cache.