A few comments. I'm not sure if the disassembly is the right one. Supposedly it is in a function called "fftwf_guru64_kosherp", but it should be in "really_have_neon".
There I would expect that the actual disassembly results in the the signal SIGILL not being reset and "return 1" always being executed. Then the error pattern would make sense. I will check this tonight when I have access to my ARM hardware. Regarding the use of intrinsics: AFAICS in configure.ac --with-neon always sets HAVE_NEON as define and adds the flag -mfpu=neon. In addition the gcc manpage says: "If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations are not generated by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified." With this in mind I would suggest the attached patch. Best Gert
--- simd-support/neon.c.old 2014-10-29 12:57:25.627329195 +0100
+++ simd-support/neon.c 2014-10-29 13:02:34.465717330 +0100
@@ -23,8 +23,23 @@
#if HAVE_NEON
-/* check for an environment where signals are known to work */
-#if defined(unix) || defined(linux)
+
+/* check for an environment where getauxval exists */
+#if defined(linux)
+ #include <sys/auxv.h>
+
+ int X(have_simd_neon)(void)
+ {
+ static int init = 0, res;
+ if (!init) {
+ res = !!(getauxval(AT_HWCAP) & HWCAP_ARM_NEON);
+ init = 1;
+ }
+ return res;
+ }
+
+/* otherwise check for signals */
+#elif defined(unix)
# include <signal.h>
# include <setjmp.h>
@@ -44,10 +59,9 @@
signal(SIGILL, oldsig);
return 0;
} else {
- /* paranoia: encode the instruction in binary because the
- assembler may not recognize it without -mfpu=neon */
- /*asm volatile ("vand q0, q0, q0");*/
- asm volatile (".long 0xf2000150");
+ /* --with-neon sets HAVE_NEON and -mfpu=neon, so we are save */
+ asm volatile ("vand q0, q0, q0");
+
signal(SIGILL, oldsig);
return 1;
}
signature.asc
Description: This is a digitally signed message part
