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

> -----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.

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

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