Re: GCC floating point usage

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Tue, 15 Oct 2002 15:25:11 -0700
> From: Mark Mitchell <mark@codesourcery.com>

> --On Tuesday, October 15, 2002 02:51:29 PM -0700 Geoff Keating 
> <geoffk@geoffk.org> wrote:
> 
...
> > * I note that the patch doesn't include any documentation at all.  A
> > version of the patch submitted for approval should have full
> > documentation.  For instance, it should say whether the flag is merely
> > an optimisation hint, or whether there is actually a promise that GCC
> > will not use FPRs and under what circumstances.  Only then can we
> > decide if this is really the feature that people seem to want.
> 
> It seems to me we'd better start here.  There's no point in producing
> patches if the RS6000 maintainers aren't going to accept them.
> 
> Some operating systems (VxWorks, for example) do not do FP
> save/restore when switching between tasks unless the task has
> explicitly indicated that it wants this to be done.
> 
> The result is that when you are in a task that has not indicated that
> it wants FP save/restore you absolutely must not write to the FP
> registers.  If you write to one of the FP registers you have actually
> written on the data from some other task.
> 
> So, the documentation of the flag would be something like:
> 
>   With this flag, GCC will only use floating-point instructions if your
>   program explicitly uses floating-point computations at the source level.
>   It will not generate floating-point instructions in other circumstances.
> 
> If that means playing with setjmp, consider that to be part of the above
> statement.  It's not a hint; it's a command.

OK, that's a good description.  It's clear, easily understood, and has
a bunch of consequences I bet you haven't thought of yet :-).

For instance, consider a program that uses setjmp in one file, which
contains no use of FP but uses routines from another file that call
longjmp and do use FP.

> The long-standing practice on VxWorks has been that the compiler
> decided whether to generate FP instructions based on the presence of
> FP at the source level.  This is convenient for programmers -- they
> don't have to think about whether they're in an FP task or not when
> they write Makefiles and most code.  So, on VxWorks, the flag would
> default to "on"; on most other targets it would be "off" to match
> existing behavior.
> 
> One could argue that this is not the right approach; that, rather,
> the programmer should have to be aware of whether or not they're in
> an FP task at all times, and specify that with an explicit switch,
> like -msoft-float.

Note that this doesn't apply to "most code"; assuming vxworks defaults
to -msoft-float, then -mhard-float is only necessary when it's
actually necessary to use the FPU.

>  That's not necessarily unreasonable, but it's not
> what VxWorks programmers are accustomed to doing, and it sounds like
> there are other embedded users who would also like the VxWorks approach.
> 
> So, let's first answer the question: would you accept a patch which had
> the behavior above, assuming it were otherwise OK?

It's not a black-and-white issue.  A small, simple, obviously correct
patch that implements the feature would be much more acceptable than a
large complex buggy patch.  The feature isn't of such great utility
that it's worth a large maintenance headache.

-- 
- Geoffrey Keating <geoffk@geoffk.org>