My target platform is ARM cortex-A7 with VFP/neon enabled, where my system software running on the target platform does not always turn VPF/neon on but turn on VPF/neon only on demand (by calling some system API).
My tool chain is a bare-metal GCC-4.7.4 cross-compiler on pc-cygwin host (arm-none-eabi).
We have a C source file
a.c, the code may run when system software turns VPF/neon off. This
a.c code is pure integer with intensive
long long (64-bit integer) operations. If applying the GCC option
-mfloat-abi=softfp to compile
a.c, some instructions to use VFP/neon registers will be generated (such as,
vstr d7,[sp,..], etc). If running this generated code when VFP/neon is off, an undefined fault happens on target platform. If applying the GCC option
-mfloat-abi=soft to compile
a.c, no VFP/neon register will be used and solve the undefined fault problem.
On the other hand, there is another C source file
b.c, which contains floating points/vectors (VFP/neon) operations and runs only if when system software turns on VFP/neon. I’d like to compile
b.c with the GCC option
-mfloat-abi=hard instead of
-mfloat-abi=softfp for performance reason.
b.c is compiled with
a.c is compiled with
-mfloat-abi=soft option, they cannot be linked together and the linker will complain: “…Uses VFP register arguments, XXX does not”.
Is there any way (with tool chain GCC options, installation configurations, versions) to compile the said pure integer
a.c compatible with hard-float ABI (passing floating point arguments via VFP/neon registers) but without generating any VFP/neon instruction or register for pure integer operations?
- As a workaround,
-mfloat-abi=softfpcan be linked, but poorer performance is not desirable.
- The GCC 4.9 release notes said “.. Use of Advanced SIMD (Neon) for 64-bit scalar computations has been disabled by default. This was found to generate better code in only a small number of cases. It can be turned back on with the
-mneon-for-64bitsoption”. This seems to be related to my problem, but I am using GCC 4.7.4.