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
