Re: GCC floating point usage

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Wed, 16 Oct 2002 11:11:53 -0700
> From: Mark Mitchell <mark@codesourcery.com>

> Geoff --
> 
> OK, so we've had some more discussion on the list.
> 
> Driving forward, we're still at the point where we need a decision on
> whether you will accept a patch to implement the feature as specified,
> if clean, etc.
> 
> So, will you?

We don't have a spec yet.  You have a spec, and Zack has a partial
spec and a patch, and they're all three different.  I think I said I
liked your spec, I don't like Zack's patch for reasons I detailed
including lack of an English spec, and Zack's spec is marginal: I'd
like to see the "documented set of primitives".  (Part of that set
should be the list of all the things that can set has_nonlocal_label.)

For reference, these are the two English specs we have:

Mark's spec:
>   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.

Zack's spec:
> The intent is that it's a guarantee that floating-point instructions
> will not be *executed* by a function compiled under -mno-implicit-fp,
> unless that function either (a) uses floating point numbers, or (b)
> uses a small, documented set of primitives where the implementation
> has to use floating point even if the caller doesn't (such as
> setjmp/longjmp).

I think that Mike had yet another spec in mind, in which using certain
primitives (like setjmp, EH, etc.) in this situation is user error and
causes undefined behaviour, but I'm not sure.

> If so, why is it that simply turning off the bits in the MD that allow
> for these register->register copies is wrong?

That would depend on two things:

(a) Does this affect codegen when the new feature is not enabled?
    Zack's patch does, and it shouldn't.
(b) Does this actually do what the spec claims?  To decide this, we
    have to settle on a spec.

>  I can see that it might not result in optimal code in that in a
> function which is already doing FP stuff at the source level, you
> might as well do FP moves -- but nobody has yet proposed a way of
> doing better that as even close to being as simple and reliable as
> Zack's patch.

The obvious way to do this is to create an entry in struct function,
set by the middle-end, "current_function_uses_float", and then use that
to determine whether the stfd/lfd/fmr instructions are available in
the backend.

I don't consider Zack's patch to be very simple, considering its
impacts on reload, and have no evidence as to its reliability.

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