* GCC floating point usage @ 2002-10-14 9:59 Stefan Bylund 2002-10-14 10:16 ` David Edelsohn 0 siblings, 1 reply; 40+ messages in thread From: Stefan Bylund @ 2002-10-14 9:59 UTC (permalink / raw) To: gcc [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 9:59 GCC floating point usage Stefan Bylund @ 2002-10-14 10:16 ` David Edelsohn 2002-10-14 10:25 ` Zack Weinberg 2002-10-14 10:37 ` Stefan Bylund 0 siblings, 2 replies; 40+ messages in thread From: David Edelsohn @ 2002-10-14 10:16 UTC (permalink / raw) To: Stefan Bylund; +Cc: gcc >>>>> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 10:16 ` David Edelsohn @ 2002-10-14 10:25 ` Zack Weinberg 2002-10-14 10:55 ` Dale Johannesen 2002-10-14 22:22 ` Mark Mitchell 2002-10-14 10:37 ` Stefan Bylund 1 sibling, 2 replies; 40+ messages in thread From: Zack Weinberg @ 2002-10-14 10:25 UTC (permalink / raw) To: David Edelsohn; +Cc: Stefan Bylund, gcc 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))" ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 10:25 ` Zack Weinberg @ 2002-10-14 10:55 ` Dale Johannesen 2002-10-14 22:22 ` Mark Mitchell 1 sibling, 0 replies; 40+ messages in thread From: Dale Johannesen @ 2002-10-14 10:55 UTC (permalink / raw) To: Zack Weinberg; +Cc: Dale Johannesen, David Edelsohn, Stefan Bylund, gcc 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.) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 10:25 ` Zack Weinberg 2002-10-14 10:55 ` Dale Johannesen @ 2002-10-14 22:22 ` Mark Mitchell 2002-10-15 15:35 ` Geoff Keating 1 sibling, 1 reply; 40+ messages in thread From: Mark Mitchell @ 2002-10-14 22:22 UTC (permalink / raw) To: Zack Weinberg, David Edelsohn; +Cc: Stefan Bylund, gcc --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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 22:22 ` Mark Mitchell @ 2002-10-15 15:35 ` Geoff Keating 2002-10-15 16:10 ` Mark Mitchell ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Geoff Keating @ 2002-10-15 15:35 UTC (permalink / raw) To: Mark Mitchell; +Cc: Stefan Bylund, gcc 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 15:35 ` Geoff Keating @ 2002-10-15 16:10 ` Mark Mitchell 2002-10-15 17:20 ` Geoff Keating 2002-10-15 17:19 ` Mike Stump 2002-10-15 18:41 ` Zack Weinberg 2 siblings, 1 reply; 40+ messages in thread From: Mark Mitchell @ 2002-10-15 16:10 UTC (permalink / raw) To: Geoff Keating; +Cc: Stefan Bylund, gcc --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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 16:10 ` Mark Mitchell @ 2002-10-15 17:20 ` Geoff Keating 2002-10-15 18:09 ` Mark Mitchell 2002-10-15 19:04 ` Mike Stump 0 siblings, 2 replies; 40+ messages in thread From: Geoff Keating @ 2002-10-15 17:20 UTC (permalink / raw) To: mark; +Cc: steby, gcc > 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 17:20 ` Geoff Keating @ 2002-10-15 18:09 ` Mark Mitchell 2002-10-16 7:40 ` Joel Sherrill 2002-10-15 19:04 ` Mike Stump 1 sibling, 1 reply; 40+ messages in thread From: Mark Mitchell @ 2002-10-15 18:09 UTC (permalink / raw) To: Geoff Keating; +Cc: steby, gcc, zack > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 18:09 ` Mark Mitchell @ 2002-10-16 7:40 ` Joel Sherrill 0 siblings, 0 replies; 40+ messages in thread From: Joel Sherrill @ 2002-10-16 7:40 UTC (permalink / raw) To: Mark Mitchell; +Cc: Geoff Keating, steby, gcc, zack 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 17:20 ` Geoff Keating 2002-10-15 18:09 ` Mark Mitchell @ 2002-10-15 19:04 ` Mike Stump 2002-10-16 12:06 ` Mark Mitchell 2002-10-16 13:43 ` Richard Henderson 1 sibling, 2 replies; 40+ messages in thread From: Mike Stump @ 2002-10-15 19:04 UTC (permalink / raw) To: Geoff Keating; +Cc: mark, steby, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 19:04 ` Mike Stump @ 2002-10-16 12:06 ` Mark Mitchell 2002-10-16 13:35 ` Geoff Keating 2002-10-16 13:43 ` Richard Henderson 1 sibling, 1 reply; 40+ messages in thread From: Mark Mitchell @ 2002-10-16 12:06 UTC (permalink / raw) To: Mike Stump, Geoff Keating; +Cc: steby, gcc 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 12:06 ` Mark Mitchell @ 2002-10-16 13:35 ` Geoff Keating 2002-10-16 14:29 ` Mark Mitchell 2002-10-17 4:12 ` Mike Stump 0 siblings, 2 replies; 40+ messages in thread From: Geoff Keating @ 2002-10-16 13:35 UTC (permalink / raw) To: mark; +Cc: mrs, steby, gcc > 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 13:35 ` Geoff Keating @ 2002-10-16 14:29 ` Mark Mitchell 2002-10-16 14:56 ` Michael Matz 2002-10-17 4:12 ` Mike Stump 1 sibling, 1 reply; 40+ messages in thread From: Mark Mitchell @ 2002-10-16 14:29 UTC (permalink / raw) To: Geoff Keating; +Cc: mrs, steby, gcc > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 14:29 ` Mark Mitchell @ 2002-10-16 14:56 ` Michael Matz 2002-10-16 15:03 ` Mark Mitchell 0 siblings, 1 reply; 40+ messages in thread From: Michael Matz @ 2002-10-16 14:56 UTC (permalink / raw) To: Mark Mitchell; +Cc: Geoff Keating, mrs, steby, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 14:56 ` Michael Matz @ 2002-10-16 15:03 ` Mark Mitchell 2002-10-16 15:27 ` David Edelsohn 0 siblings, 1 reply; 40+ messages in thread From: Mark Mitchell @ 2002-10-16 15:03 UTC (permalink / raw) To: Michael Matz; +Cc: Geoff Keating, mrs, steby, gcc --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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 15:03 ` Mark Mitchell @ 2002-10-16 15:27 ` David Edelsohn 2002-10-16 15:36 ` Mark Mitchell 2002-10-16 17:57 ` Mike Stump 0 siblings, 2 replies; 40+ messages in thread From: David Edelsohn @ 2002-10-16 15:27 UTC (permalink / raw) To: Mark Mitchell; +Cc: Michael Matz, Geoff Keating, mrs, steby, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 15:27 ` David Edelsohn @ 2002-10-16 15:36 ` Mark Mitchell 2002-10-16 16:35 ` Zack Weinberg ` (2 more replies) 2002-10-16 17:57 ` Mike Stump 1 sibling, 3 replies; 40+ messages in thread From: Mark Mitchell @ 2002-10-16 15:36 UTC (permalink / raw) To: David Edelsohn; +Cc: Michael Matz, Geoff Keating, mrs, steby, gcc > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 15:36 ` Mark Mitchell @ 2002-10-16 16:35 ` Zack Weinberg 2002-10-16 16:36 ` Mark Mitchell 2002-10-16 16:46 ` David Edelsohn 2002-10-17 8:37 ` Paul Koning 2 siblings, 1 reply; 40+ messages in thread From: Zack Weinberg @ 2002-10-16 16:35 UTC (permalink / raw) To: Mark Mitchell Cc: David Edelsohn, Michael Matz, Geoff Keating, mrs, steby, gcc 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 16:35 ` Zack Weinberg @ 2002-10-16 16:36 ` Mark Mitchell 0 siblings, 0 replies; 40+ messages in thread From: Mark Mitchell @ 2002-10-16 16:36 UTC (permalink / raw) To: Zack Weinberg Cc: David Edelsohn, Michael Matz, Geoff Keating, mrs, steby, gcc --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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 15:36 ` Mark Mitchell 2002-10-16 16:35 ` Zack Weinberg @ 2002-10-16 16:46 ` David Edelsohn 2002-10-17 8:37 ` Paul Koning 2 siblings, 0 replies; 40+ messages in thread From: David Edelsohn @ 2002-10-16 16:46 UTC (permalink / raw) To: Mark Mitchell; +Cc: Michael Matz, Geoff Keating, mrs, steby, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 15:36 ` Mark Mitchell 2002-10-16 16:35 ` Zack Weinberg 2002-10-16 16:46 ` David Edelsohn @ 2002-10-17 8:37 ` Paul Koning 2 siblings, 0 replies; 40+ messages in thread From: Paul Koning @ 2002-10-17 8:37 UTC (permalink / raw) To: mark; +Cc: dje, matz, geoffk, mrs, steby, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 15:27 ` David Edelsohn 2002-10-16 15:36 ` Mark Mitchell @ 2002-10-16 17:57 ` Mike Stump 1 sibling, 0 replies; 40+ messages in thread From: Mike Stump @ 2002-10-16 17:57 UTC (permalink / raw) To: David Edelsohn; +Cc: Mark Mitchell, Michael Matz, Geoff Keating, steby, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 13:35 ` Geoff Keating 2002-10-16 14:29 ` Mark Mitchell @ 2002-10-17 4:12 ` Mike Stump 1 sibling, 0 replies; 40+ messages in thread From: Mike Stump @ 2002-10-17 4:12 UTC (permalink / raw) To: Geoff Keating; +Cc: mark, steby, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 19:04 ` Mike Stump 2002-10-16 12:06 ` Mark Mitchell @ 2002-10-16 13:43 ` Richard Henderson 2002-10-16 14:35 ` Mark Mitchell 2002-10-16 17:29 ` Mike Stump 1 sibling, 2 replies; 40+ messages in thread From: Richard Henderson @ 2002-10-16 13:43 UTC (permalink / raw) To: Mike Stump; +Cc: Geoff Keating, mark, steby, gcc 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~ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 13:43 ` Richard Henderson @ 2002-10-16 14:35 ` Mark Mitchell 2002-10-16 14:56 ` Joel Sherrill 2002-10-16 16:38 ` Richard Henderson 2002-10-16 17:29 ` Mike Stump 1 sibling, 2 replies; 40+ messages in thread From: Mark Mitchell @ 2002-10-16 14:35 UTC (permalink / raw) To: Richard Henderson, Mike Stump; +Cc: Geoff Keating, steby, gcc > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 14:35 ` Mark Mitchell @ 2002-10-16 14:56 ` Joel Sherrill 2002-10-16 16:38 ` Richard Henderson 1 sibling, 0 replies; 40+ messages in thread From: Joel Sherrill @ 2002-10-16 14:56 UTC (permalink / raw) To: Mark Mitchell; +Cc: Richard Henderson, Mike Stump, Geoff Keating, steby, gcc 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 14:35 ` Mark Mitchell 2002-10-16 14:56 ` Joel Sherrill @ 2002-10-16 16:38 ` Richard Henderson 2002-10-16 16:53 ` Zack Weinberg 1 sibling, 1 reply; 40+ messages in thread From: Richard Henderson @ 2002-10-16 16:38 UTC (permalink / raw) To: Mark Mitchell; +Cc: Mike Stump, Geoff Keating, steby, gcc 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~ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 16:38 ` Richard Henderson @ 2002-10-16 16:53 ` Zack Weinberg 2002-10-16 17:52 ` Michael Matz 2002-10-16 22:50 ` Richard Henderson 0 siblings, 2 replies; 40+ messages in thread From: Zack Weinberg @ 2002-10-16 16:53 UTC (permalink / raw) To: Richard Henderson, Mark Mitchell, Mike Stump, Geoff Keating, steby, gcc 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 16:53 ` Zack Weinberg @ 2002-10-16 17:52 ` Michael Matz 2002-10-16 22:50 ` Richard Henderson 1 sibling, 0 replies; 40+ messages in thread From: Michael Matz @ 2002-10-16 17:52 UTC (permalink / raw) To: Zack Weinberg Cc: Richard Henderson, Mark Mitchell, Mike Stump, Geoff Keating, steby, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 16:53 ` Zack Weinberg 2002-10-16 17:52 ` Michael Matz @ 2002-10-16 22:50 ` Richard Henderson 2002-10-21 12:21 ` Jeff Law 1 sibling, 1 reply; 40+ messages in thread From: Richard Henderson @ 2002-10-16 22:50 UTC (permalink / raw) To: Zack Weinberg; +Cc: Mark Mitchell, Mike Stump, Geoff Keating, steby, gcc 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~ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 22:50 ` Richard Henderson @ 2002-10-21 12:21 ` Jeff Law 0 siblings, 0 replies; 40+ messages in thread From: Jeff Law @ 2002-10-21 12:21 UTC (permalink / raw) To: Richard Henderson Cc: Zack Weinberg, Mark Mitchell, Mike Stump, Geoff Keating, steby, gcc 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~ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 13:43 ` Richard Henderson 2002-10-16 14:35 ` Mark Mitchell @ 2002-10-16 17:29 ` Mike Stump 2002-10-17 2:19 ` Richard Henderson 1 sibling, 1 reply; 40+ messages in thread From: Mike Stump @ 2002-10-16 17:29 UTC (permalink / raw) To: Richard Henderson; +Cc: Geoff Keating, mark, steby, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-16 17:29 ` Mike Stump @ 2002-10-17 2:19 ` Richard Henderson 0 siblings, 0 replies; 40+ messages in thread From: Richard Henderson @ 2002-10-17 2:19 UTC (permalink / raw) To: Mike Stump; +Cc: Geoff Keating, mark, steby, gcc 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~ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 15:35 ` Geoff Keating 2002-10-15 16:10 ` Mark Mitchell @ 2002-10-15 17:19 ` Mike Stump 2002-10-15 18:41 ` Zack Weinberg 2 siblings, 0 replies; 40+ messages in thread From: Mike Stump @ 2002-10-15 17:19 UTC (permalink / raw) To: Geoff Keating; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 15:35 ` Geoff Keating 2002-10-15 16:10 ` Mark Mitchell 2002-10-15 17:19 ` Mike Stump @ 2002-10-15 18:41 ` Zack Weinberg 2002-10-16 1:48 ` Fergus Henderson 2 siblings, 1 reply; 40+ messages in thread From: Zack Weinberg @ 2002-10-15 18:41 UTC (permalink / raw) To: Geoff Keating; +Cc: Mark Mitchell, Stefan Bylund, gcc 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-15 18:41 ` Zack Weinberg @ 2002-10-16 1:48 ` Fergus Henderson 0 siblings, 0 replies; 40+ messages in thread From: Fergus Henderson @ 2002-10-16 1:48 UTC (permalink / raw) To: Zack Weinberg; +Cc: Geoff Keating, Mark Mitchell, Stefan Bylund, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 10:16 ` David Edelsohn 2002-10-14 10:25 ` Zack Weinberg @ 2002-10-14 10:37 ` Stefan Bylund 2002-10-14 11:28 ` Mike Stump 1 sibling, 1 reply; 40+ messages in thread From: Stefan Bylund @ 2002-10-14 10:37 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 10:37 ` Stefan Bylund @ 2002-10-14 11:28 ` Mike Stump 2002-10-14 12:39 ` Joel Sherrill 0 siblings, 1 reply; 40+ messages in thread From: Mike Stump @ 2002-10-14 11:28 UTC (permalink / raw) To: Stefan Bylund; +Cc: David Edelsohn, gcc 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: GCC floating point usage 2002-10-14 11:28 ` Mike Stump @ 2002-10-14 12:39 ` Joel Sherrill 0 siblings, 0 replies; 40+ messages in thread From: Joel Sherrill @ 2002-10-14 12:39 UTC (permalink / raw) To: Mike Stump; +Cc: Stefan Bylund, David Edelsohn, gcc 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2002-10-21 16:45 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-10-14 9:59 GCC floating point usage Stefan Bylund 2002-10-14 10:16 ` David Edelsohn 2002-10-14 10:25 ` Zack Weinberg 2002-10-14 10:55 ` Dale Johannesen 2002-10-14 22:22 ` Mark Mitchell 2002-10-15 15:35 ` Geoff Keating 2002-10-15 16:10 ` Mark Mitchell 2002-10-15 17:20 ` Geoff Keating 2002-10-15 18:09 ` Mark Mitchell 2002-10-16 7:40 ` Joel Sherrill 2002-10-15 19:04 ` Mike Stump 2002-10-16 12:06 ` Mark Mitchell 2002-10-16 13:35 ` Geoff Keating 2002-10-16 14:29 ` Mark Mitchell 2002-10-16 14:56 ` Michael Matz 2002-10-16 15:03 ` Mark Mitchell 2002-10-16 15:27 ` David Edelsohn 2002-10-16 15:36 ` Mark Mitchell 2002-10-16 16:35 ` Zack Weinberg 2002-10-16 16:36 ` Mark Mitchell 2002-10-16 16:46 ` David Edelsohn 2002-10-17 8:37 ` Paul Koning 2002-10-16 17:57 ` Mike Stump 2002-10-17 4:12 ` Mike Stump 2002-10-16 13:43 ` Richard Henderson 2002-10-16 14:35 ` Mark Mitchell 2002-10-16 14:56 ` Joel Sherrill 2002-10-16 16:38 ` Richard Henderson 2002-10-16 16:53 ` Zack Weinberg 2002-10-16 17:52 ` Michael Matz 2002-10-16 22:50 ` Richard Henderson 2002-10-21 12:21 ` Jeff Law 2002-10-16 17:29 ` Mike Stump 2002-10-17 2:19 ` Richard Henderson 2002-10-15 17:19 ` Mike Stump 2002-10-15 18:41 ` Zack Weinberg 2002-10-16 1:48 ` Fergus Henderson 2002-10-14 10:37 ` Stefan Bylund 2002-10-14 11:28 ` Mike Stump 2002-10-14 12:39 ` Joel Sherrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).