Hi Joey Thank you for explanations. Now I have some comments and additional questions. Since now it will be a discussion rather than looking for help, I am re-routing the discussion to GCC mailing list. For those looking for the complete history, here is the context: http://gcc.gnu.org/ml/gcc-help/2012-10/msg00055.html
On 09.10.2012 12:21, Joey Ye wrote: [snip] >> On 24.09.2012 12:30, Ilija Kocho wrote: >>> Hi colleagues >>> >>> In a course of implementing lazy context switching I the following >>> link come to me: >>> >>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DA >>> FIFGGE.html >>> [snip] >>> Therefore here are my questions: >>> >>> 1) Does GCC use VFP registers for holding data other than floating >>> point values (unsolicited VFP usage)? > It doesn't so far. Although GCC has no problem use FP for non-FP, the cost > model in ARM backend says using VFP isn't performing better than otherwise. > > For Cortex-M4F this isn't the best approach. I worked out a patch to tune > the cost model for M4F together with an option to enable/disable it. I'm > hoping to submit it later this year and it should enable Cortex-M4F to use > VFP extensively for non-FP data when option enabled. > >>> If (1) is true: >>> 1.1) What conditions, in addition to selecting -mfloat-abi=hard (or >>> softfp) shall cause such behaviour. I would appreciate some test case. > When the patch is upstreamed, and given that -ffpreg-for-nonfpdata is > provided, VFP will be used for non-FP data when ever register pressure is > high. > [snip] >> 1.4) Can it be disabled? I found no such command line option for ARM >> targets. > The command line will be as -f[no-]fpreg-for-nonfpdata According to current GCC conventions shoulfn't it begin with "m" i.e. -m[no]fpreg-for-nonfpdata ? >>> 2) Above quote states that -mfloat-abi=soft should be used for libs, but >>> ld refuses to link them with code produced with -mfloat-abi=hard even if >>> the libs do not use floating point operations. Is there a waay to tweak >>> this? > The quote isn't accurate nowadays. More and more libraries are built with > hard. Also a mechanism called multilib enables you to pick soft or hard > automatically according to linker command line Although I am not GCC expert I am aware of multilibs. Indeed, I have succeeded in building of GCC with a pretty rich multilib collection. But my point is: at present, due to floating point ABI incompatibility, we can't link functions/libs compiled with -mfloat-abi=soft flag to functions/libs compiled with -mfloat-abi=hard flag, regardless whether floating point is effectively in use or not. But, won't particular functions, that _do not_ use floating point, effectively have same ABI regardless of flags used (-mfloat-abi=soft or -mfloat-abi=hard)? Then shouldn't it be possible to link them to both /soft/ and /hard/ float-abi code? Any comments? Ilija
