This is the mail archive of the gcc@gcc.gnu.org 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: GCC floating point usage


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.


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