This is the mail archive of the 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

On 10.10.2012 06:05, Joey Ye wrote:
>> -----Original Message-----
>> From: Ilija Kocho []
>> Sent: Tuesday, October 09, 2012 21:08
>> To: Joey Ye
>> Cc:; 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:
>> 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:
>>>>> 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


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