This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC floating point usage
On Tue, Oct 15, 2002 at 02:51:29PM -0700, 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.
Right now, the only changes I know need to be made are to add
documentation, and to invert the default setting of the switch, which
I intend to do by flipping the sense of the target_flags bit. This
avoids having to change all the existing settings of TARGET_DEFAULT.
> > 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.
Can you explain why you believe this? In the !TARGET_IMPLICIT_FP
situation, there is no MD pattern that will issue lfd/stfd for a
DImode move *unless there is no other alternative*. The reason we
need that exception is, the integer<->FP conversion patterns
(correctly, since this is an architectural requirement) expect to be
able to place integers in FPU registers.
> (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
It's true that this patch controls the behavior of the compiler at
translation-unit granularity; I can work up something with function
granularity, if that's desirable. Translation-unit granularity was
good enough for Wind River so that's what I implemented.
> (b) the machine does in fact have the capability to use DImode moves,
> in integer registers, and the patch does reflect this.
I'm not sure what you're trying to get at here.
> 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.
Erm. How is what I did not controlling it at the point of register
allocation? Actually, re-reading the description of the "*"
constraint modifier, I think that I was wrong to bring up initial RTL
generation at all. I think what happens is GCC *does* generate a
DImode move using pseudos, then the register allocator cannot allocate
the pseudo to an "f" register so it uses an integer register pair
instead.
> * 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.
I can only say that it worked in all of my testing.
I'm open to an alternate implementation. I'm just not sure what that
alternate implementation should be.
> * 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.
First, to clarify, as Mike said downthread, what matters is not
whether floating point instructions are issued by the compiler, but
whether they can be executed at run time.
IIRC, empirically, call-frame exceptions don't execute floating point
instructions unless floating point registers actually need to be
restored by a throw. SJLJ exceptions and setjmp/longjmp themselves
do. My client was willing to stipulate that nothing could be done
about that, and that code which used setjmp/longjmp or exceptions had
to be used in a context where FPU access was safe.
> * 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.
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).
zw