Re: GCC floating point usage

[Mike Stump <mrs at apple dot com>]

On Tuesday, October 15, 2002, at 02:51 PM, Geoff Keating 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:
>
> * I don't believe the patch is correct; that is, I don't think it does
> what Zack claims it does.
It's been experimentally verified that it comes within the measuring 
limits that it in fact it does for the cases the patch was wanted.  If 
you know of a testcase that won't work, please, let us know, we can try 
it, and then see if your claim that it doesn't work is valid, if no 
such testcase exists, then it comes fairly close to original claim.

>   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.
Ok, maybe it does.  Maybe there will be a bug that we will have to fix 
in the future.  Should the possible existence of a bug prohibit the 
feature?

> * 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
I think this might be due to a misunderstanding of the feature.  I 
think the key is the difference between, there is no use of floating 
point in the function versus there is no floating point in the 
execution path at run time.  Zack should be able to clarify or confirm.

> 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.
As I recall, that was too late.  The register allocator sees the DI 
mode values and moves and such, and allocates a DI register.  Nothing 
wrong with that.

> setjmp and exceptions are not strictly "optimization"s (neither is
> varargs), and they both have this property.
First, this is most useful for C for a variety of reasons, this is 
where people care the most.  A system setjmp is free to know when FP is 
in use or not.  The EH mechanisms sometimes have to work on systems 
where the FP unit is disabled, or when register sets are not always 
there (altivec).  The FP regs can be handled just like the altivec 
registers? Roughly, how the are (or should be, if not alrady), if there 
is a bit that says they've been used, then it is safe to play with the 
regs, if not, one should not play with them.  If this is an unfixed 
bug, then yes, for completeness and to support C++, Java, Ada, it would 
be nice to fix EH.

> * I note that the patch doesn't include any documentation at all.  A
> version of the patch submitted for approval should have full
> documentation.
Agreed.