Re: GCC floating point usage

[Mike Stump <mrs at apple dot com>]

On Wednesday, October 16, 2002, at 01:14 PM, Richard Henderson wrote:
> On Tue, Oct 15, 2002 at 05:20:07PM -0700, Mike Stump wrote:
> > A routine that is compiled with no-implicit-fp is valid to use in a
> > no-FP task, provided there is no explicit fp in it.  A routine that
> > isn't compiled with this flag isn't valid to use in a non-FP task.
> No, that's not correct.
I must not have expressed myself well enough for you to have understood 
what I was trying to say.

> A routine that doesn't use FP is valid to use in a no-FP task.
Not always.  There are two cases, the code was compiled with 
no-implicit-fp, in that case, trivially, the code is valid to use in a 
no-FP task.  If code wasn't compiled with this flag, then it is invalid 
to use the code in a no-FP task.  Honest.  Your phrase above doesn't 
contradict what I meant to say.  Note, when we speak of routines that 
use FP, we a first order approximation of what we mean is that the word 
double or the word float appears in the source code, we don't mean 
anything that is based upon inspection of compiler codegen.  Zack's 
phrasing I think describes this well enough.

If you mean to suggest how the compiler should work in the future, 
instead of how it works today, then it does seem reasonable to take 
that approach.  We were just concerned about removing registers from 
the allocator for most folks that use OSes that always context switch 
those register or because they fault and mark such tasks as needing FP 
context switching.  I think 90%+ of the people are in this later 
category.

> A routine that does use explicit fp is not valid to use in a no-FP 
> task.
Again, this doesn't contradict anything I meant to say.  Yes, this is 
trivially true.

> I think that the proper solution to this to have a mode in which
> the compiler does not *prefer* to use FP registers for integral
> data.  But the assembler would set a bit if any FP registers are
> used, which would then be collected by the linker to indicate
> whether or not the process as a whole uses FP registers.
This is nice, but it doesn't solve the problem people want to solve.  
It doesn't offer a replacement for the functionality that Zack wants.

We want a single .o to be able to contain FP routines, and non-FP 
routines, and to be able to start tasks that are either FP tasks or 
not, and for those tasks to make calls into the routines arbitrarily 
and for the user to know that the floating point registers are not 
going to be stomped on.

> Anything less is asking for trouble.
>
> The only other solution is to use -msoft-float.  The argument that
> that changes calling conventions is nonsense -- given that this
> is supposed to be a no-FP process, we've already established that
> we're not supposed to be using FP whatsoever.
This indicates you don't understand why the flag is wanted yet.  A 
single .o exists and can have 1 or more tasks runnning code from that 
.o, and each task can be either a FP task, or a non-FP task, as choosen 
at task creation time, and fixed for the duration of that task.

We've already seen the problems associated with -msoft-float, they are 
real and do exist.  -msoft-float isn't a solution as it changes the abi 
of some hard float routines.  The hard float code and the non-FP code 
live side by side in the same translation units but different functions.