GCC floating point usage

GCC floating point usage

[Stefan Bylund]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

In GCC 3.2 for powerpc-eabi, when enabling hardware floating point, GCC will
generate floating point instructions not only for C/C++ float/double operations
but also internally for optimizing non-floating point 64-bit data transfers etc.

Is it possible to somehow instruct GCC to only generate floating point
instructions for C/C++ float/double operations and not for internal non-floating
point optimizations etc?

/Stefan


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Card for Stefan Bylund --]
[-- Type: text/x-vcard; charset=us-ascii; name="steby.vcf", Size: 275 bytes --]

begin:vcard 
n:Bylund;Stefan
tel;cell:+46 709 714 325
tel;work:+46 8 507 143 25
x-mozilla-html:FALSE
url:http://www.ose.com
org:OSE Systems
adr:;;Nytorpsvägen 5;Täby;;183 23;Sweden
version:2.1
email;internet:steby@enea.se
title:Software Engineer
fn:Stefan Bylund
end:vcard

Re: GCC floating point usage

[David Edelsohn]

>>>>> Stefan Bylund writes:

Stefan> In GCC 3.2 for powerpc-eabi, when enabling hardware floating point, GCC will
Stefan> generate floating point instructions not only for C/C++ float/double operations
Stefan> but also internally for optimizing non-floating point 64-bit data transfers etc.

Stefan> Is it possible to somehow instruct GCC to only generate floating point
Stefan> instructions for C/C++ float/double operations and not for internal non-floating
Stefan> point optimizations etc?

	If you do not want to use the FPU, then invoke the compiler with
the -msoft-float PowerPC option.  If the FPRs are present and it is
efficient to use them, the compiler will use them.

David

Re: GCC floating point usage

[Zack Weinberg]

On Mon, Oct 14, 2002 at 12:37:14PM -0400, David Edelsohn wrote:
> >>>>> Stefan Bylund writes:
> 
> Stefan> Is it possible to somehow instruct GCC to only generate
> Stefan> floating point instructions for C/C++ float/double
> Stefan> operations and not for internal non-floating point
> Stefan> optimizations etc?
> 
> 	If you do not want to use the FPU, then invoke the compiler with
> the -msoft-float PowerPC option.  If the FPRs are present and it is
> efficient to use them, the compiler will use them.

Come now, what he wants is not unreasonable.  "If floating point
operations appeared in the source code, generate hardware floating
point instructions; otherwise, generate only integer-unit
instructions."  I (that is, CodeSourcery) have a customer that needs
precisely this; in fact I posted a patch to implement it for PPC last
fall.  Now seems like a reasonable time to bring the issue back up.

My old patch, against the 3.2 branch, is appended to this message.  It
is not quite suitable for inclusion in its present form - for one
thing, the default is off, which makes sense for the customer I did
the patch for, but not for most users of the RS6000/PPC back end.
Also, it needs checking that it still fits on the mainline.

I recall that this patch was shot down when originally submitted, on
the grounds that the fix should instead modify exp*.c to avoid
generating DImode moves in the first place.  I do not buy this
argument.  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.  Also,
this patch can be counted on to suppress all DImode floating-point
load/store instructions, whatever part of the compiler might have
generated them; changing exp*.c would not provide any guarantee that
some other pass would not decide to do the same thing.

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

zw

--- config/rs6000/rs6000.h	2002-08-29 18:44:28 -0700
+++ config/rs6000/rs6000.h	2002-10-01 18:27:53 -0700
@@ -222,7 +222,11 @@
 #define MASK_AIX_STRUCT_RET	0x00100000
 #define MASK_AIX_STRUCT_RET_SET	0x00200000
 
-/* The only remaining free bit is 0x00400000. sysv4.h uses
+/* Permit the use of floating point registers for DImode temporaries.
+   Only makes sense in 32-bit mode.  */
+#define MASK_IMPLICIT_FP	0x00400000
+
+/* There are no remaining free bits.  sysv4.h uses
    0x00800000 -> 0x40000000, and 0x80000000 is not available
    because target_flags is signed.  */
 
@@ -246,6 +250,7 @@
 #define TARGET_SCHED_PROLOG	(target_flags & MASK_SCHED_PROLOG)
 #define TARGET_ALTIVEC		(target_flags & MASK_ALTIVEC)
 #define TARGET_AIX_STRUCT_RET	(target_flags & MASK_AIX_STRUCT_RET)
+#define TARGET_IMPLICIT_FP	(target_flags & MASK_IMPLICIT_FP)
 
 #define TARGET_32BIT		(! TARGET_64BIT)
 #define TARGET_HARD_FLOAT	(! TARGET_SOFT_FLOAT)
@@ -370,6 +375,10 @@
 			""},\
   {"no-svr4-struct-return", MASK_AIX_STRUCT_RET | MASK_AIX_STRUCT_RET_SET,\
 			""},\
+  {"implicit-fp",	MASK_IMPLICIT_FP,\
+			N_("Use floating point registers to optimize integer code")},\
+  {"no-implicit-fp",	- MASK_IMPLICIT_FP,\
+			N_("Don't use floating point registers to optimize integer code")},\
   SUBTARGET_SWITCHES							\
   {"",			TARGET_DEFAULT | MASK_SCHED_PROLOG,		\
 			""}}
--- config/rs6000/rs6000.md	2002-09-27 15:51:05 -0700
+++ config/rs6000/rs6000.md	2002-10-01 18:27:57 -0700
@@ -8353,9 +8353,30 @@
   ""
   "{ rs6000_emit_move (operands[0], operands[1], DImode); DONE; }")
 
+;; This movdi pattern handles only DImode floating-point load and
+;; store.  It is used exclusively for optimization, when we are
+;; allowed to use floating point registers for DImode temporaries
+;; (controlled by -m(no-)implicit-fp).
+(define_insn "*movdi_internal32_fpu"
+  [(set (match_operand:DI 0 "nonimmediate_operand" "=f,f,m")
+	(match_operand:DI 1 "input_operand"        "f,m,f"))]
+  "! TARGET_POWERPC64 && TARGET_IMPLICIT_FP
+   && (gpc_reg_operand (operands[0], DImode)
+       || gpc_reg_operand (operands[1], DImode))"
+  "@
+   fmr %0,%1
+   lfd%U1%X1 %0,%1
+   stfd%U0%X0 %1,%0"
+  [(set_attr "type" "fp,fpload,fpstore")
+   (set_attr "length" "*,*,*")])
+
+;; This is the general movdi for 32-bit processors.  It will accept
+;; moves to floating point registers, but only if forced by other
+;; instructions' constraints (for instance, because the fixdfdi
+;; pattern leaves its output in an FPR).
 (define_insn "*movdi_internal32"
-  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m,f,f,m,r,r,r,r,r")
-	(match_operand:DI 1 "input_operand" "r,m,r,f,m,f,IJK,n,G,H,F"))]
+  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m,*f,*f,m,r,r,r,r,r")
+	(match_operand:DI 1 "input_operand" "r,m,r,*f,m,*f,IJK,n,G,H,F"))]
   "! TARGET_POWERPC64
    && (gpc_reg_operand (operands[0], DImode)
        || gpc_reg_operand (operands[1], DImode))"

Re: GCC floating point usage

[Stefan Bylund]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

The reason why I am asking this is because in the OSE RTOS, the kernel will only save the
floating point registers for a process at context switch if that process has ever used a
floating point register. If a process never uses a floating point register its context
switch will be more efficient. So, if a process executes code that utilizes the floating
point registers for non-floating point purposes, its context switches will be less
efficient. Ideally, we only want processes that actually uses the floating point registers
for actual floating point purposes to pay the price of a less efficient context switch.

/Stefan


David Edelsohn wrote:

> >>>>> Stefan Bylund writes:
>
> Stefan> In GCC 3.2 for powerpc-eabi, when enabling hardware floating point, GCC will
> Stefan> generate floating point instructions not only for C/C++ float/double operations
> Stefan> but also internally for optimizing non-floating point 64-bit data transfers etc.
>
> Stefan> Is it possible to somehow instruct GCC to only generate floating point
> Stefan> instructions for C/C++ float/double operations and not for internal non-floating
> Stefan> point optimizations etc?
>
>         If you do not want to use the FPU, then invoke the compiler with
> the -msoft-float PowerPC option.  If the FPRs are present and it is
> efficient to use them, the compiler will use them.
>
> David

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Card for Stefan Bylund --]
[-- Type: text/x-vcard; charset=us-ascii; name="steby.vcf", Size: 275 bytes --]

begin:vcard 
n:Bylund;Stefan
tel;cell:+46 709 714 325
tel;work:+46 8 507 143 25
x-mozilla-html:FALSE
url:http://www.ose.com
org:OSE Systems
adr:;;Nytorpsvägen 5;Täby;;183 23;Sweden
version:2.1
email;internet:steby@enea.se
title:Software Engineer
fn:Stefan Bylund
end:vcard

Re: GCC floating point usage

[Dale Johannesen]

On Monday, October 14, 2002, at 09:59  AM, Zack Weinberg wrote:
> On Mon, Oct 14, 2002 at 12:37:14PM -0400, David Edelsohn wrote:
>>>>>>> Stefan Bylund writes:
>> Stefan> Is it possible to somehow instruct GCC to only generate
>> Stefan> floating point instructions for C/C++ float/double
>> Stefan> operations and not for internal non-floating point
>> Stefan> optimizations etc?
>>
>> 	If you do not want to use the FPU, then invoke the compiler with
>> the -msoft-float PowerPC option.  If the FPRs are present and it is
>> efficient to use them, the compiler will use them.
>
> Come now, what he wants is not unreasonable.  "If floating point
> operations appeared in the source code, generate hardware floating
> point instructions; otherwise, generate only integer-unit
> instructions."  I (that is, CodeSourcery) have a customer that needs
> precisely this; in fact I posted a patch to implement it for PPC last
> fall.  Now seems like a reasonable time to bring the issue back up.

Apple's group has users who want this also.  From one viewpoint the real
problem is that the compiler's idea of "efficient to use them" is not
always accurate; but doing better may require information not available
to the compiler, as in Stefan Bylund's case.  Overall I think a patch
of this sort is a good idea.

(We also have users who carefully write double stores to zero out an 
array,
and are annoyed when the compiler changes them into two int stores.
[Actually a mix may be better than either.]  I wouldn't mind having 
Zach's
switch, or another switch, disable this behavior also.)

Re: GCC floating point usage

[Mike Stump]

On Monday, October 14, 2002, at 10:10 AM, Stefan Bylund wrote:
> The reason why I am asking this is because in the OSE RTOS, the kernel 
> will only save the floating point registers for a process at context 
> switch

And this is the same reason that Wind River needs the patch.

Re: GCC floating point usage

[Joel Sherrill]

Mike Stump wrote:
> 
> On Monday, October 14, 2002, at 10:10 AM, Stefan Bylund wrote:
> > The reason why I am asking this is because in the OSE RTOS, the kernel
> > will only save the floating point registers for a process at context
> > switch
> 
> And this is the same reason that Wind River needs the patch.

RTEMS is in the same boat.  Right now, the PowerPC port lies and
considers all tasks are floating point to work around this.  

This would be a nice improvement for embedded PowerPC users.  

Using -msoft-float is unacceptable for RTEMS applications 
because it means that some portions of the single executable
would have to be linked against -msoft-float libraries and others
against hardware float variants.  

NOTE: We initially encountered this behavior in gcc doing the 
HPPA port.  As I recall, the PA port at that time used
the FPU for integer multiplies and tended to do it for indexing
arrays of odd-sized structures.  

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: GCC floating point usage

[Mark Mitchell]

--On Monday, October 14, 2002 09:59:00 AM -0700 Zack Weinberg 
<zack@codesourcery.com> wrote:

> On Mon, Oct 14, 2002 at 12:37:14PM -0400, David Edelsohn wrote:
>> >>>>> Stefan Bylund writes:
>>
>> Stefan> Is it possible to somehow instruct GCC to only generate
>> Stefan> floating point instructions for C/C++ float/double
>> Stefan> operations and not for internal non-floating point
>> Stefan> optimizations etc?
>>
>> 	If you do not want to use the FPU, then invoke the compiler with
>> the -msoft-float PowerPC option.  If the FPRs are present and it is
>> efficient to use them, the compiler will use them.
>
> Come now, what he wants is not unreasonable.  "If floating point
> operations appeared in the source code, generate hardware floating
> point instructions; otherwise, generate only integer-unit
> instructions."  I (that is, CodeSourcery) have a customer that needs
> precisely this; in fact I posted a patch to implement it for PPC last
> fall.  Now seems like a reasonable time to bring this issue back up.

I agree, on all points:

(1) Clearly, many people have a real need for this fuctionality.

(2) You are correct; if the user has told the compiler not to use
    hardware FP unless floating point operations appear in the code,
    then the MD should not pretend it knows how to do moves that it
    can only do with FP registers.

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.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Geoff Keating]

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>

Re: GCC floating point usage

[Mark Mitchell]

--On Tuesday, October 15, 2002 02:51:29 PM -0700 Geoff Keating 
<geoffk@geoffk.org> 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:

Good.

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

It seems to me we'd better start here.  There's no point in producing
patches if the RS6000 maintainers aren't going to accept them.

Some operating systems (VxWorks, for example) do not do FP
save/restore when switching between tasks unless the task has
explicitly indicated that it wants this to be done.

The result is that when you are in a task that has not indicated that
it wants FP save/restore you absolutely must not write to the FP
registers.  If you write to one of the FP registers you have actually
written on the data from some other task.

So, the documentation of the flag would be something like:

  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.

The long-standing practice on VxWorks has been that the compiler
decided whether to generate FP instructions based on the presence of
FP at the source level.  This is convenient for programmers -- they
don't have to think about whether they're in an FP task or not when
they write Makefiles and most code.  So, on VxWorks, the flag would
default to "on"; on most other targets it would be "off" to match
existing behavior.

One could argue that this is not the right approach; that, rather,
the programmer should have to be aware of whether or not they're in
an FP task at all times, and specify that with an explicit switch,
like -msoft-float.  That's not necessarily unreasonable, but it's not
what VxWorks programmers are accustomed to doing, and it sounds like
there are other embedded users who would also like the VxWorks approach.

So, let's first answer the question: would you accept a patch which had
the behavior above, assuming it were otherwise OK?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Mike Stump]

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.

Re: GCC floating point usage

[Geoff Keating]

> Date: Tue, 15 Oct 2002 15:25:11 -0700
> From: Mark Mitchell <mark@codesourcery.com>

> --On Tuesday, October 15, 2002 02:51:29 PM -0700 Geoff Keating 
> <geoffk@geoffk.org> wrote:
> 
...
> > * 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.
> 
> It seems to me we'd better start here.  There's no point in producing
> patches if the RS6000 maintainers aren't going to accept them.
> 
> Some operating systems (VxWorks, for example) do not do FP
> save/restore when switching between tasks unless the task has
> explicitly indicated that it wants this to be done.
> 
> The result is that when you are in a task that has not indicated that
> it wants FP save/restore you absolutely must not write to the FP
> registers.  If you write to one of the FP registers you have actually
> written on the data from some other task.
> 
> So, the documentation of the flag would be something like:
> 
>   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.

OK, that's a good description.  It's clear, easily understood, and has
a bunch of consequences I bet you haven't thought of yet :-).

For instance, consider a program that uses setjmp in one file, which
contains no use of FP but uses routines from another file that call
longjmp and do use FP.

> The long-standing practice on VxWorks has been that the compiler
> decided whether to generate FP instructions based on the presence of
> FP at the source level.  This is convenient for programmers -- they
> don't have to think about whether they're in an FP task or not when
> they write Makefiles and most code.  So, on VxWorks, the flag would
> default to "on"; on most other targets it would be "off" to match
> existing behavior.
> 
> One could argue that this is not the right approach; that, rather,
> the programmer should have to be aware of whether or not they're in
> an FP task at all times, and specify that with an explicit switch,
> like -msoft-float.

Note that this doesn't apply to "most code"; assuming vxworks defaults
to -msoft-float, then -mhard-float is only necessary when it's
actually necessary to use the FPU.

>  That's not necessarily unreasonable, but it's not
> what VxWorks programmers are accustomed to doing, and it sounds like
> there are other embedded users who would also like the VxWorks approach.
> 
> So, let's first answer the question: would you accept a patch which had
> the behavior above, assuming it were otherwise OK?

It's not a black-and-white issue.  A small, simple, obviously correct
patch that implements the feature would be much more acceptable than a
large complex buggy patch.  The feature isn't of such great utility
that it's worth a large maintenance headache.

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

Re: GCC floating point usage

[Mark Mitchell]

> OK, that's a good description.  It's clear, easily understood, and has
> a bunch of consequences I bet you haven't thought of yet :-).

Could well be. :-)

> For instance, consider a program that uses setjmp in one file, which
> contains no use of FP but uses routines from another file that call
> longjmp and do use FP.

I've thought of this one, though.

That's considered user error in VxWorks; no different from reading
from uninitialized memory.

> Note that this doesn't apply to "most code"; assuming vxworks defaults
> to -msoft-float, then -mhard-float is only necessary when it's
> actually necessary to use the FPU.

I said "think about" -- not actually pass the switch.  You still have
to think about in your Makefile, and in a mostly-FP task (say, a
signal processing task), you might have almost-all FP code.

>> So, let's first answer the question: would you accept a patch which had
>> the behavior above, assuming it were otherwise OK?
>
> It's not a black-and-white issue.  A small, simple, obviously correct
> patch that implements the feature would be much more acceptable than a
> large complex buggy patch.

Well, sure -- that was supposed to be the "otherwise OK" bit. :-)

Are you saying that a good patch to implement this feature would be OK,
for appropriate definition of "good"?

If so, then we can go back to the technical discussion about how best
to implement the imaginary flag.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Zack Weinberg]

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

Re: GCC floating point usage

[Mike Stump]

On Tuesday, October 15, 2002, at 04:37 PM, Geoff Keating wrote:
> OK, that's a good description.  It's clear, easily understood, and has
> a bunch of consequences I bet you haven't thought of yet :-).
>
> For instance, consider a program that uses setjmp in one file, which
> contains no use of FP but uses routines from another file that call
> longjmp and do use FP.

I believe that case has been thought of.  The thing that is marked as 
FP or not, is a task.  A task that is not marked as FP cannot by 
definition call a routine that is in a task that does use FP.  No 
problem here.

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.

> Note that this doesn't apply to "most code"; assuming vxworks defaults
> to -msoft-float,

It does not.  It multilibs softfloat.  On softfloat system, the entire 
implicit-fp issue it a non-issue, so we don't care about those.  The 
only case we care about is by definition on hardfloat systems, when the 
context switcher may, or may not save/restore the FP regs.

Re: GCC floating point usage

[Fergus Henderson]

On 15-Oct-2002, Zack Weinberg <zack@codesourcery.com> wrote:
> SJLJ exceptions and setjmp/longjmp themselves do [execute floating
> point instructions].  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.

If that is the case, then it should be explained in the documentation for
this feature.  Also, it would be nice if the comiler issued a warning
if the proposed -mno-implicit-fp flag is enabled and setjmp/longjmp is called,
e.g. "warning: -mno-implicit-fp not supported for setjmp/longjmp",
and likewise for SJLJ exceptions.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: GCC floating point usage

[Joel Sherrill]

Mark Mitchell wrote:
> 
> > OK, that's a good description.  It's clear, easily understood, and has
> > a bunch of consequences I bet you haven't thought of yet :-).
> 
> Could well be. :-)
> 
> > For instance, consider a program that uses setjmp in one file, which
> > contains no use of FP but uses routines from another file that call
> > longjmp and do use FP.
> 
> I've thought of this one, though.
> 
> That's considered user error in VxWorks; no different from reading
> from uninitialized memory.

RTEMS considers this an error as well and uses whatever CPU features
are available to keep non-FP tasks from executing FP code.  This is
how we discovered the use of the FPU on the PowerPC.  Tasks would 
fault because the FPU was disabled.  I know that at least the SPARC
and MIPS ports disable the FPU for integer only tasks.

FWIW it is also an error for the user to explicitly inline FPU
instructions
or invoke libm routines from a non-FPU tasks.

> > Note that this doesn't apply to "most code"; assuming vxworks defaults
> > to -msoft-float, then -mhard-float is only necessary when it's
> > actually necessary to use the FPU.
> 
> I said "think about" -- not actually pass the switch.  You still have
> to think about in your Makefile, and in a mostly-FP task (say, a
> signal processing task), you might have almost-all FP code.

Be careful with the -msoft-float line of thinking.  That not only
impacts code generation, it has an impact on which multilib library
variants the application can be linked with.  You can't mix and
match at link time.  For example, you want the hard float printf
variant but the non-FPU tasks doesn't print floating point numbers.

And as an aside, embedded C libraries often have something like
iprintf() which is a strictly integer printf variant.

> >> So, let's first answer the question: would you accept a patch which had
> >> the behavior above, assuming it were otherwise OK?
> >
> > It's not a black-and-white issue.  A small, simple, obviously correct
> > patch that implements the feature would be much more acceptable than a
> > large complex buggy patch.
> 
> Well, sure -- that was supposed to be the "otherwise OK" bit. :-)
> 
> Are you saying that a good patch to implement this feature would be OK,
> for appropriate definition of "good"?
> 
> If so, then we can go back to the technical discussion about how best
> to implement the imaginary flag.
> 
> --
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: GCC floating point usage

[Mark Mitchell]

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?

If so, why is it that simply turning off the bits in the MD that allow
for these register->register copies is wrong?  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.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Geoff Keating]

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

Re: GCC floating point usage

[Richard Henderson]

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.

A routine that doesn't use FP is valid to use in a no-FP task.

A routine that does use explicit fp is not valid to use in a no-FP task.


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.

In this way, if gcc does happen to use an FP register, due to
queer register pressure/preferencing, then we're still ok, because
the process *is* marked as an FP process.

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.



r~

Re: GCC floating point usage

[Mark Mitchell]

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

I think that Zack and Mike mean the same thing, and that I was close,
but slightly off.  Obviously, it doesn't matter whether the compiler
generates FP ops if they can never be executed.  (In fact, it doesn't
really matter if it stuffs totally random bytes into the text
section if you can't ever get there.)

So, perhaps, amend my spec to say "will not generate floating-point
instructions that can ever be executed by a program that does not
call setjmp or throw an exception."

> (a) Does this affect codegen when the new feature is not enabled?
>     Zack's patch does, and it shouldn't.

I certainly agree that people not using the flag should see no change.

Why does Zack's patch do that, given his caveat that the sense of the
flag would be reversed so that the flag is off by default?

> 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 guess that would work; you would test the flag in the predicate for
the instruction.  That will, however, be a more invasive patch (you
have to try to find all the places in the middle end where floats might
be used).

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Mark Mitchell]

> 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 a dynamic property; not a static one.  Linking in printf is
fine, if you never call it with "%g", and you know that it doesn't
use floating-point registers otherwise.  You don't want two printfs;
memory is tight, and you want to be able to share your one printf
between tasks.

You just don't want the compiler to generate FP register moves for
integer programs.

> Anything less is asking for trouble.

Yes, programmers have to be very careful not to accidentally let FP
slip into no-FP tasks.  But, hey, we're in C on embedded systems; we
have to be careful about lots of things.  This is just one more...

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Michael Matz]

Hi,

On Wed, 16 Oct 2002, Mark Mitchell wrote:

> > (a) Does this affect codegen when the new feature is not enabled?
> >     Zack's patch does, and it shouldn't.
>
> I certainly agree that people not using the flag should see no change.
>
> Why does Zack's patch do that, given his caveat that the sense of the
> flag would be reversed so that the flag is off by default?

Because it adds an additional insn pattern, with equal predicates as
the following one, but with different constraints.  This means, that in
the case this pattern is activated (which it is by default, given Zacks
changed default proposal) it will be preferred, which means, because it
only lists float regs in constraints, that float regs will be preferred.

Indeed I'm not even sure, that the second pattern will be used at all (if
the first is activated), because for insn recognition only predicates are
used, which make the first pattern match.  Then when reload is running it
doesn't rerecognize the insn, and instead reloads all operands of this
insn into either float regs or memory, which means, that _no_ integer regs
would be used at all for it.  That's one of the reason for the requirement
that things allowed by the predicates need to have at least one
alternative which accepts them.  And also that it's suboptimal to have
non-disjoint sets of predicates (i.e. which are active at the same time,
and match the same insns) with different constraints.


Ciao,
Michael.

Re: GCC floating point usage

[Joel Sherrill]

Mark Mitchell wrote:
> 
> > 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 a dynamic property; not a static one.  Linking in printf is
> fine, if you never call it with "%g", and you know that it doesn't
> use floating-point registers otherwise.  You don't want two printfs;
> memory is tight, and you want to be able to share your one printf
> between tasks.

As an aside which will have to be rechecked when this all settles,
at one point, the code generated for the newlib printf actually 
touched the FPU even if you did not use a FP format specifier.  I
believe
this was triggered by having local float/double variables even
though they were not used.  I recall that the code was modified to
add local scope blocks and declare them closer to the point of
use.
 
> You just don't want the compiler to generate FP register moves for
> integer programs.

Right.  Also at least the HPPA port used to do integer multiplies
in the FPU so move may not be the only case.

> > Anything less is asking for trouble.
> 
> Yes, programmers have to be very careful not to accidentally let FP
> slip into no-FP tasks.  But, hey, we're in C on embedded systems; we
> have to be careful about lots of things.  This is just one more...

Yes.  And given a tiny bit of hardware help, the run-time can enforce
that no-FP tasks do not utilize the FPU. 

> --
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: GCC floating point usage

[Mark Mitchell]

--On Wednesday, October 16, 2002 10:53:33 PM +0200 Michael Matz 
<matz@suse.de> wrote:

> Hi,
>
> On Wed, 16 Oct 2002, Mark Mitchell wrote:
>
>> > (a) Does this affect codegen when the new feature is not enabled?
>> >     Zack's patch does, and it shouldn't.
>>
>> I certainly agree that people not using the flag should see no change.
>>
>> Why does Zack's patch do that, given his caveat that the sense of the
>> flag would be reversed so that the flag is off by default?
>
> Because it adds an additional insn pattern, with equal predicates as
> the following one, but with different constraints.  This means, that in
> the case this pattern is activated (which it is by default, given Zacks
> changed default proposal) it will be preferred, which means, because it
> only lists float regs in constraints, that float regs will be preferred.

That sounds like a problem that needs to be fixed.

We're still hung up on a more basic problem, though; the RS6000
maintainers haven't yet made an up-or-down decision on the idea of
the flag...

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> We're still hung up on a more basic problem, though; the RS6000
Mark> maintainers haven't yet made an up-or-down decision on the idea of
Mark> the flag...

	I do not fundamentally object to a commandline option, for some
set of semantics which remains ambigous in this discussion, IMHO.  I would
prefer if GCC implicitly avoided referencing FPRs in functions that do not
otherwise use floating point computations instead of an explicit option.

	I believe there are problems with the implementations of the flag
presented so far, both from a GCC Internals perspective (e.g., reload) and
a code generation perspective (e.g., emitting two successive GPR load or
store instructions which are not scheduled).

	I am reserving final judgment until I see a complete definition of
the semantics and an implementation that is more universally accepted as
correct.  Neither Geoff nor I want to take on the maintenance burden of a
flawed patch.

David

Re: GCC floating point usage

[Mark Mitchell]

> 	I am reserving final judgment until I see a complete definition of
> the semantics and an implementation

If maintainers take the attitude that they will not make a judgement
about semantics before seeing an implementation, the bar has been set
too high.

There is no reason that a contributor should have to actually implement
something before we decide if we want it.  We should say "yes, that
is a feature we want" or "no, it is not".  Obviously, we don't want it
at any cost; if it is a ten-thousand line horribly ugly patch for a
not-terribly-desirable feature, it's not a winner.  But, we should be
able to say "yes, that feature is a good one; if the patch is small and
clean we'll take it."

Since you think the semantics are unclear, I'll make an effort to state
them again:

  If the user does not explicitly use floating point at the source
  level, the compiler will not generate reads to or writes from the
  floating point registers that can ever be executed by the program,
  unless that program calls "setjmp" or makes use of exception-handling.

We can define "at the source level" to mean something appropriate for
every programming language in question; in the case of C and C++:

  To use floating point at the source level in C or C++ means:

  - To declare an automatic variable of floating point type.
  - To define a function with a parameter of floating point type, or
    a return value of floating point type.
  - To write any expression which has a floating point type.

The C standard defines "floating point type", or some very similar term,
as meaning "float", "double", or "long double".

Will you accept a patch to implement those semantics?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Zack Weinberg]

On Wed, Oct 16, 2002 at 02:54:29PM -0700, Mark Mitchell wrote:
> Since you think the semantics are unclear, I'll make an effort to state
> them again:
> 
>  If the user does not explicitly use floating point at the source
>  level, the compiler will not generate reads to or writes from the
>  floating point registers that can ever be executed by the program,
>  unless that program calls "setjmp" or makes use of exception-handling.

I would prefer to phrase it thus:

  The compiler will not generate floating point instructions that can
  ever be executed by the program, unless either

  (a) the source code of the program makes use of floating point, or

  (b) the source code of the program contains constructs which -
  although not explicitly using floating point - cannot be implemented
  in an ABI-compatible manner without causing the compiled program to
  execute floating point instructions.

  Examples of such constructs are: exception handling, setjmp,
  longjmp, and variadic functions.  This list is not necessarily
  exhaustive, nor do all of these constructs necessarily require
  floating point.

[On the PowerPC, the SVR4 ABI allows variadic functions to be used
without executing floating point instructions, as long as no actual
argument has a floating point type.  This is not true of other ABIs.
For instance, some ABIs for the SH with hardware floating point do
require any variadic function to execute floating point instructions
in its prologue.]

[As that comment might suggest, a version of this feature that's
architecture independent would be preferred by the people who
originally asked me to implement it.  I don't presently see any way to
do it in an architecture-independent fashion, but I'm open to
suggestions.]

Your description of what "the source code of the program makes use of
floating point" means for C, works for me.

zw

Re: GCC floating point usage

[Mark Mitchell]

--On Wednesday, October 16, 2002 03:16:05 PM -0700 Zack Weinberg 
<zack@codesourcery.com> wrote:

> On Wed, Oct 16, 2002 at 02:54:29PM -0700, Mark Mitchell wrote:
>> Since you think the semantics are unclear, I'll make an effort to state
>> them again:
>>
>>  If the user does not explicitly use floating point at the source
>>  level, the compiler will not generate reads to or writes from the
>>  floating point registers that can ever be executed by the program,
>>  unless that program calls "setjmp" or makes use of exception-handling.
>
> I would prefer to phrase it thus:
>
>   The compiler will not generate floating point instructions that can
>   ever be executed by the program, unless either
>
>   (a) the source code of the program makes use of floating point, or
>
>   (b) the source code of the program contains constructs which -
>   although not explicitly using floating point - cannot be implemented
>   in an ABI-compatible manner without causing the compiled program to
>   execute floating point instructions.
>
>   Examples of such constructs are: exception handling, setjmp,
>   longjmp, and variadic functions.  This list is not necessarily
>   exhaustive, nor do all of these constructs necessarily require
>   floating point.

OK.

Let's go with that version; you know what you're talking about better
than I do.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC floating point usage

[Richard Henderson]

On Wed, Oct 16, 2002 at 01:33:36PM -0700, Mark Mitchell wrote:
> >Anything less is asking for trouble.
> 
> Yes, programmers have to be very careful not to accidentally let FP
> slip into no-FP tasks.

No, what I mean is that I'm with Geoff: you won't be able to
guarantee that the compiler does the right thing without a
completely different approach.

You're going to need the front/middle-end to indicate whether
"floating point has been used", and if not, hide *all* existance
of the fp registers from the register allocators.  Nothing less
gives you assurance they won't be used.


r~

Re: GCC floating point usage

[David Edelsohn]

>>>>> Mark Mitchell writes:


>> I am reserving final judgment until I see a complete definition of
>> the semantics and an implementation

Mark> If maintainers take the attitude that they will not make a judgement
Mark> about semantics before seeing an implementation, the bar has been set
Mark> too high.

Mark> There is no reason that a contributor should have to actually implement
Mark> something before we decide if we want it.  We should say "yes, that
Mark> is a feature we want" or "no, it is not".  Obviously, we don't want it
Mark> at any cost; if it is a ten-thousand line horribly ugly patch for a
Mark> not-terribly-desirable feature, it's not a winner.  But, we should be
Mark> able to say "yes, that feature is a good one; if the patch is small and
Mark> clean we'll take it."

	How about whether the patch is safe and correct?  For this
feature, the next level of semantics are tied up with the details of the
eventual implementation.  In the best of all worlds, the compiler should
be able to generate optimal code avoiding FPRs without a commandline
option to promote lazy FP context switching.

	What you described as the general concept for improved code
generation is a good goal.  I do not know whether that concept can be
implemented safely, correctly, and cleanly.  If the FPRs are available and
the compiler is not smart enough to avoid them optimally, it is better to
use them.

Mark> Will you accept a patch to implement those semantics?

	I would like to, but it depends on the details of the patch.

David

Re: GCC floating point usage

[Zack Weinberg]

On Wed, Oct 16, 2002 at 03:27:24PM -0700, Richard Henderson wrote:
> On Wed, Oct 16, 2002 at 01:33:36PM -0700, Mark Mitchell wrote:
> > >Anything less is asking for trouble.
> > 
> > Yes, programmers have to be very careful not to accidentally let FP
> > slip into no-FP tasks.
> 
> No, what I mean is that I'm with Geoff: you won't be able to
> guarantee that the compiler does the right thing without a
> completely different approach.
> 
> You're going to need the front/middle-end to indicate whether
> "floating point has been used", and if not, hide *all* existance
> of the fp registers from the register allocators.  Nothing less
> gives you assurance they won't be used.

Okay.  Care to suggest how this should be accomplished?

zw

Re: GCC floating point usage

[Mike Stump]

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.

Re: GCC floating point usage

[Michael Matz]

Hi,

On Wed, 16 Oct 2002, Zack Weinberg wrote:

> > No, what I mean is that I'm with Geoff: you won't be able to
> > guarantee that the compiler does the right thing without a
> > completely different approach.
> >
> > You're going to need the front/middle-end to indicate whether
> > "floating point has been used", and if not, hide *all* existance
> > of the fp registers from the register allocators.  Nothing less
> > gives you assurance they won't be used.
>
> Okay.  Care to suggest how this should be accomplished?

Multiple possibilities: either change fixed_regs[] per function to either
include or exclude those special regs, based on information from the
frontend or middleend.

Or create a regclass for all regs you intend to hide (FLOAT_REGS for
instance).  Subtract that class from the possible hardreg candidates for
pseudos in regclass.c (or probably better directly in global.c, or even
right in reload*.c).  Look e.g. for STACK_REGS in global.c how a similar
case is handled.  Do this also conditionalized on information on the
front/middleend.  If that information is incorrect you might end up with
reload aborting (e.g. when you indeed have insn which only accept floats,
while disallowing them).


Ciao,
Michael.

Re: GCC floating point usage

[Mike Stump]

On Wednesday, October 16, 2002, at 02:34 PM, David Edelsohn wrote:
> I would prefer if GCC implicitly avoided referencing FPRs in functions 
> that do not otherwise use floating point computations instead of an 
> explicit option.

This would be fine to the people that wanted the flag.

Re: GCC floating point usage

[Richard Henderson]

On Wed, Oct 16, 2002 at 03:36:45PM -0700, Zack Weinberg wrote:
> > You're going to need the front/middle-end to indicate whether
> > "floating point has been used", and if not, hide *all* existance
> > of the fp registers from the register allocators.  Nothing less
> > gives you assurance they won't be used.
> 
> Okay.  Care to suggest how this should be accomplished?

For the second part?

Arrange for REG_CLASS_FROM_LETTER to return NO_REGS for 'f' 
when appropriate would be one way.  Mistakes here would result
in reload aborts, since reload would fail to find a way to 
move data between, into, or out of the FP regs.

Marking the fp registers to be fixed for the duration of the
function would be another way, though it would seem that you'd
need a new hook run from rest_of_compilation, somewhere before
regclass/reload, in order to make this work.


r~

Re: GCC floating point usage

[Richard Henderson]

On Wed, Oct 16, 2002 at 04:31:35PM -0700, Mike Stump wrote:
> This indicates you don't understand why the flag is wanted yet.

No, I understood, just don't agree with the stated usage model.
I think it's far too prone to user error.


r~

Re: GCC floating point usage

[Mike Stump]

On Wednesday, October 16, 2002, at 12:55 PM, Geoff Keating wrote:
> 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 don't think the differences are intentional.

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

No.  I don't.  I can map my onto his, or his onto mine.  If you see 
differences, then these are areas ripe for improvement in the 
documentation.  I see them as the same, as I know what he means, and I 
know what I mean.

Re: GCC floating point usage

[Paul Koning]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

 Mark> ...Since you think the semantics are unclear, I'll make an effort
 Mark> to state them again:

 Mark> If the user does not explicitly use floating point at the
 Mark> source level, the compiler will not generate reads to or writes
 Mark> from the floating point registers that can ever be executed by
 Mark> the program, unless that program calls "setjmp" or makes use of
 Mark> exception-handling.

Why are setjmp and exception handling excluded from the rule?  If a
program doesn't use floating point registers, then setjmp and
exception handling have no need to do so, either.

It may be that a particular platform has these services implemented in
such a way that they unconditional fiddle with the float registers.
But that need not be true for all platforms, so the
platform-independent statement of the intended semantics should not
make this rule as far as I can see.

     paul

Re: GCC floating point usage

[Jeff Law]

In message <20021016234620.GH30823@redhat.com>, Richard Henderson writes:
 >Arrange for REG_CLASS_FROM_LETTER to return NO_REGS for 'f' 
 >when appropriate would be one way.  Mistakes here would result
 >in reload aborts, since reload would fail to find a way to 
 >move data between, into, or out of the FP regs.
 >
 >Marking the fp registers to be fixed for the duration of the
 >function would be another way, though it would seem that you'd
 >need a new hook run from rest_of_compilation, somewhere before
 >regclass/reload, in order to make this work.
We used (still?) do the latter on a function-wide basis on at least
the PA port to prevent FP resources from ever being used when compiling
kernels and the like.

The only downside was you got an unfriendly abort if something went wrong.

It shouldn't be terribly hard to be able to make fixed_regs vary on a
function by function basis if indeed this is what folks want to do.

jeff
 >
 >
 >r~