Neon Simd For All...

[ldesnogu]

Hi! Just checking back on the state of pandora dev. Is NEON SIMD intrinsics supported by current compilers by now?

CSL 2008q3 has an intrinsics file. Does it work? Can't say, I am not sure intrinsics are the way to go

 

[synkro]

I am pretty sure that intrinsics are the way to go. You should not rely on the compiler to make things tight and right. Can you have a test run on the intrinsics, please?

 

[ldesnogu]

I am pretty sure that intrinsics are the way to go. You should not rely on the compiler to make things tight and right.

And that's exactly why you shouldn't use intrinsics: you don't know how the compilers will use them. What I originally meant is that you'd better stick with assembler if you start considering intrinsics.

QUOTE
Can you have a test run on the intrinsics, please?

I am not interested in that. OTOH you can download CSL compiler and give it a try yourself Look here.

 

[Squidge]

I agree. I remember using an intrinsic function in the IAR compiler, and rather than just inserting the op code, it called a sub-routine which contained it!

 

[synkro]

QUOTE
I am not interested in that. OTOH you can download CSL compiler and give it a try yourself Look here.



I have no Beagleboard or Pandora dev unit to actually execute code. I could look into the assembly but that's actually what I don't like.

QUOTE
I agree. I remember using an intrinsic function in the IAR compiler, and rather than just inserting the op code, it called a sub-routine which contained it!



Ouch, well if the intrinsics are implemented bad ... By not relying on the compiler I meant auto-vectorisation. I never saw that working any good without user direction (like OpenMP). As I don't like assembly I see intrinsics as good way to apply a SMID approach. This for example works rather good on the PS3.

 

[Tramboi]

I am pretty sure that intrinsics are the way to go. You should not rely on the compiler to make things tight and right.

And that's exactly why you shouldn't use intrinsics: you don't know how the compilers will use them. What I originally meant is that you'd better stick with assembler if you start considering intrinsics.

I beg to differ : GCC intrinsics are definitely the way to go to provide fast functions *that can be inlined and peephole-optimized* by the compiler.
Once you get the contraints and clobbers right, you can leverage really nice stuff for the application coder without him knowing a bit about the opcode specifics.
For instance you can have a SIMD vector class that allows anybody to generate non-trivial vector assembly from readable C++.

Definitely works good on the PS2 and PS3 toolchains as synkro said.

 

[ldesnogu]

I beg to differ : GCC intrinsics are definitely the way to go to provide fast functions *that can be inlined and peephole-optimized* by the compiler.
Once you get the contraints and clobbers right, you can leverage really nice stuff for the application coder without him knowing a bit about the opcode specifics.
For instance you can have a SIMD vector class that allows anybody to generate non-trivial vector assembly from readable C++.

Definitely works good on the PS2 and PS3 toolchains as synkro said.

Aren't you mixing up gcc inline assembler and intrinsics? As far as I know intrinsics don't have constraints, while gcc inline assembler has them. And inline assembler is certainly ugly...

Anyway I agree you have a point that intrinsics are useful to get SIMD basic types. But again if what you're looking for is maximum speed, assembly is the way to go, especially as gcc is currently not good at vectorizing (at least for NEON), and I'm not sure intrinsics would help a lot for automatic vectorization.

Now we could start playing with gcc to prove the usefulness of intrinsics for NEON. Who will start?

 

[Tramboi]

Oops, sorry, I was thinking intrinsic register types not intrinsic functions.

Intrinsic functions are very useful if the compiler is good enough at register allocation and scheduling and doesn't have codegen bugs. x86 GCC and MSVC are up to the task, I don't know about our situation, it has to be stress-tested with real apps I guess

(You are right, intrinsics have no relation to automatic vectorization, they just allow you to leverage special instructions not available in the HLL)

 

[sindbad]

There's also the problem of using NEON in higher level languages, same as with SSE. Mono's new vector classes in Mono.Simd should be easy enough to port to NEON and the DSP, but in general anything other than C and C++ gets the hose. Even D.

 

[synkro]

So, anyone had a go on pushing NEON code trough the pandora? NEON + intrinsics finally usable with current tool chains?