Hello, > If __ARM_ENON__ is defined, the compiler assumes NEON is available and can > emit NEON opcodes for plain C code. In particular, any code that parses > /proc/cpuinfo for "Features:.*neon" under #ifdef __ARM_NEON__ is completely > *non-sensical*. Yes, this include patch 1 of 4 in your patchset - I already > pointed that out but nobody seemed to pay attention. ah, I see your point the assumption is that the cross-compilation environment passes meaningful CC and/or CFLAGS and PulseAudio takes advantage if NEON is available I agree that the runtime-check for NEON is a bit pointless and can be dropped > "-mfpu=neon", then the compiler assumes the code will run ONLY on > NEON-capable ARM devices. If you want to do run-time detection, you MUST > NOT pass the corresponding compiler flag. (The same is true of MMX and SSE > by the way.) so the simple solution is to - drop the runtime check - use NEON if the compiler provides NEON if the code has to run on non-NEON platforms, NEON support cannot be enabled in the compiler the more involved solution is to - have the runtime check in place - compile code with different compiler flags - make a decision at runtime and call different code path in PulseAudio, the MMX/SSE code path use inline assembler; surprisingly (for me at least), gcc happily compiles inline assembler SSE/MMX code even with -march=i386, i.e. arch=i386 does not get passed to the assembler this behaviour makes it all too easy... :) PulseAudio simply assumes that the compiler is recent enough to know about MMX/SSE, there is no compile-time probing or checks such as #ifdef __SSE__ (fair enough) to take this solution, some build infrastructure is needed; it might be required as well for the SSE3 resampler patches in discussion this means: - probe compiler flags (such as -msse2, -mfpu=neon) - probably configure options to override - passing different compiler flags to different compilation units which route shall we go? regards, p. -- Peter Meerwald +43-664-2444418 (mobile)
