This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
- From: Ilija Kocho <ilijak at siva dot com dot mk>
- To: Joey Ye <joey dot ye at arm dot com>
- Cc: gcc at gcc dot gnu dot org, Terry Guo <Terry dot Guo at arm dot com>
- Date: Tue, 09 Oct 2012 15:08:07 +0200
- Subject: Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
- References: <email@example.com> <5073F94F.firstname.lastname@example.org> <000101cda607$e23af930$a6b0eb90$@email@example.com>
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:
On 09.10.2012 12:21, Joey Ye wrote:
>> 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:
>>> 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
>> 1.4) Can it be disabled? I found no such command line option for ARM
> The command line will be as -f[no-]fpreg-for-nonfpdata
According to current GCC conventions shoulfn't it begin with "m" i.e.
>>> 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?