Re: GCC floating point usage

[Mark Mitchell <mark at codesourcery dot com>]

--On Tuesday, October 15, 2002 02:51:29 PM -0700 Geoff Keating 
<geoffk@geoffk.org> wrote:

> Mark Mitchell <mark@codesourcery.com> writes:
>
> > With the caveat that you perserve the current default behavior, the
> > patch is OK for the b-i-b, assuming that you do not hear objections
> > from the RS6000 maintainers within a couple of days.  If they do
> > object, we will figure out what to do.
> I would like to have the final patch posted before anyone starts
> issuing approvals or disapprovals.  However, I have some comments on
> the (preliminary) patch posted:
Good.

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

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

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com