This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]