Re: GCC floating point usage

[Geoff Keating <geoffk at geoffk dot org>]

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:

* I don't believe the patch is correct; that is, I don't think it does
what Zack claims it does.  The particular claim I am not convinced by is:

> this patch can be counted on to suppress all DImode floating-point
> load/store instructions, whatever part of the compiler might have
> generated them

because it seems to me that the patch does not guarantee this, it only
encourages it.

* Also, I am not convinced by Zack's argument that:

> It seems to me that exp*.c is correct in believing the
> machine description's assertion that it has the ability to do DImode
> moves.  The correct fix is therefore to change the machine description
> so that it does not make that assertion when inappropriate.

because 

(a) The case we are concerned with is when some functions use FP, and
therefore may use FP registers, and some do not; but there is no
reflection of this in the patch; and

(b) the machine does in fact have the capability to use DImode moves,
in integer registers, and the patch does reflect this.

I can't find the original discussion of this patch, but my suggestion
would be to try to control this at the point of register allocation,
not during initial RTL generation.

* I am not enthusiastic about the construct that the patch uses in
  which the movdi pattern is split.  Is there reason to think that
  this is safe in this case?  I know that in general, it is not safe,
  as reload doesn't always re-recognize instructions.

* The following statement is correct, but misleading:

> I am not aware of any other optimization performed by GCC on the
> RS6000 that causes floating-point instructions to be executed when the
> user wrote purely integer code.  (The floating-point instructions in
> the prologue to a varargs function are not executed unless floating
> point actual arguments are passed to that function.)

setjmp and exceptions are not strictly "optimization"s (neither is
varargs), and they both have this property.

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

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