On 10.10.2012 06:05, Joey Ye wrote: > >> -----Original Message----- >> From: Ilija Kocho [mailto:ili...@siva.com.mk] >> Sent: Tuesday, October 09, 2012 21:08 >> To: Joey Ye >> Cc: gcc@gcc.gnu.org; Terry Guo >> Subject: Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F >> >> 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 ? > My typo. Should be -m. > >>>>> 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? > Then linker need to detect if there is really _no_ FP usage in a /hard/ > copy, which is difficult if not impossible.
I was looking for some kind of -force option that would allow the user to override the compiler/linker. But now since there is no unsolicited VFP usage, I can consider this as non-issue. And with option like -m[no]fpreg-for-nonfpdata it will be non issue in future too. Thank you Ilija
