Hi Kyril,

> ...
> The parts in this patch look ok to me.
> However, I think we need some more functionality
> In aarch64 we support compiling a file with no simd, including arm_neon.h and using arm_neon.h intrinsics
> within functions tagged with simd support.
> We want to support such functionality on arm i.e. compile a file with -mfpu=vfp and use arm_neon.h intrinsics
> in a function tagged with an fpu=neon attribute.
> For that we'd need to wrap the intrinsics in arm_neon.h in appropriate pragmas, like in the aarch64 version of arm_neon.h

As discussed, here is arm_neon.h for aarch32/neon with the same 
programming model than aarch64/simd. As you said lets use one of the 
fpu=neon attributes even if the file is compiled with -mfpu=vfp.

The drawback for this is that now we unconditionally makes available 
every neon intrinsics, introducing a small legacy change with regards to 
error checking (that you didn't have with aarch64). Then it's worth to 
stress that:

  - One cannot check #include "arm_neon.h" to check if the compiler can 
use neon instruction. Instead use #ifndef __ARM_NEON__.  (Found in 
target-supports.exp)

  - Types cannot be checked. For instance:

#include <arm_neon.h>

poly128_t
foo (poly128_t* ptr)
{
   return vldrq_p128 (ptr);
}

compiled with -mfpu=neon used to be rejected with

    error: unknown type name 'poly128_t' ...

  Now the error, as a side effect from the inlining rules between 
incompatible modes, becomes

   error: inlining failed in call to always_inline 'vldrq_p128': target 
specific option mismatch ...

I found this more confusing, so I was a little bit reluctant to 
implement this, but the code is correctly rejected and the message makes 
sense, after all. Just a different check.

This patch applies on top of the preceding attribute/pragma target fpu= 
series. Tested with arm-none-eabi configured with default and 
--with-cpu=cortex-a9 --with-fp --with-float=hard

Also fixes a few macro that depends on fpu=, that I forgot to redefine.

Christian