Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
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
RE: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
> -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. The whole idea of different float ABI is to avoid such kind of check or the quiet runtime error without appropriate check. No matter what motivation behinds, I won't try to interlink soft and hard from maintain-ability and stability point of view. > > Any comments? > > Ilija >
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 ? >>> 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
