public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* iso c9x unordered fp cmp builtins
@ 1998-03-01 18:35 Richard Henderson
  1998-03-01 20:11 ` David Edelsohn
  0 siblings, 1 reply; 8+ messages in thread
From: Richard Henderson @ 1998-03-01 18:35 UTC (permalink / raw)
  To: egcs

While it is possible in most cases to implement these via 
macros and asm blocks, the resulting code is hideous.  Much
better is to teach the compiler about such things.

TODO:

  - Teach constant folding about these new operators.

  - Put some sensible error message when the target md does not
    support these operators.  Currently we'll just abort with an
    unrecognized insn.

  - Teach the bulk of the backends about the new codes.


r~

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: iso c9x unordered fp cmp builtins
  1998-03-01 18:35 iso c9x unordered fp cmp builtins Richard Henderson
@ 1998-03-01 20:11 ` David Edelsohn
  1998-03-01 22:08   ` Richard Henderson
  0 siblings, 1 reply; 8+ messages in thread
From: David Edelsohn @ 1998-03-01 20:11 UTC (permalink / raw)
  To: Richard Henderson; +Cc: egcs

	When I discussed unordered compares with Ulrich last Fall, I never
was able to understand what type of NaN's the new standard is discussing.
The POWER and PowerPC architectures provide two types of FP NaNs: hard NaN
and soft NaN.  Hard NaN is a specific bit pattern that a programmer can
assign to an FP variable which always will cause an unordered exception on
FP compares.  Soft NAN is the NaN value that some FP arithmetic operations
will generate which only will cause an exception if the special unordered
compare instructions are used.

	If the new unordered conditions only are needed for user-generated
NaN, then glibc simply can arrange to place the correct NaN value in the
variable; otherwise, the port needs to be taught when to use the unordered
compares. 

Thanks, David

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: iso c9x unordered fp cmp builtins
  1998-03-01 22:08       ` Richard Henderson
@ 1998-03-01 21:52         ` David Edelsohn
  1998-03-01 22:08           ` Richard Henderson
       [not found]         ` <9803020551.AA24480.cygnus.egcs@rios1.watson.ibm.com>
  1 sibling, 1 reply; 8+ messages in thread
From: David Edelsohn @ 1998-03-01 21:52 UTC (permalink / raw)
  To: Richard Henderson; +Cc: egcs

>>>>> Richard Henderson writes:

>> Did your SPARC implementation *change* the use of those two FP
>> compare instructions?

Richard> Not with respect to normal comparisions, no.  That is, normal comparisons
Richard> do signal qnan, and as far as I can tell, always have.

	The "rs6000" port always has used fcmpu and never has signal QNaN.
This also is the behavior of IBM's XLC.  Does iso9x now mandate that the
regular comparison operators signal QNaN?  Using the fcmpo instruction and
enabling one of the varying exactness degrees of QNaN signalling in the
PowerPC FP control register imposes a performance degradation (which I
think is why it is not used by default).

David

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: iso c9x unordered fp cmp builtins
  1998-03-01 20:11 ` David Edelsohn
@ 1998-03-01 22:08   ` Richard Henderson
  1998-03-01 22:08     ` David Edelsohn
  0 siblings, 1 reply; 8+ messages in thread
From: Richard Henderson @ 1998-03-01 22:08 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Richard Henderson, egcs

On Sun, Mar 01, 1998 at 11:10:24PM -0500, David Edelsohn wrote:
> The POWER and PowerPC architectures provide two types of FP NaNs: hard NaN
> and soft NaN.  Hard NaN is a specific bit pattern that a programmer can
> assign to an FP variable which always will cause an unordered exception on
> FP compares.  Soft NAN is the NaN value that some FP arithmetic operations
> will generate which only will cause an exception if the special unordered
> compare instructions are used.

How do these compare with the signalling and quiet NaNs described in
the IEEE standard?  Are they the same thing with different names?

> 	If the new unordered conditions only are needed for user-generated
> NaN, then glibc simply can arrange to place the correct NaN value in the
> variable; otherwise, the port needs to be taught when to use the unordered
> compares. 

My understanding is that 

	quiet_nan = 0.0 / 0.0;
	isunordered(quiet_nan, 0.0);

should return true without killing the program with SIGFPE.

The way I have it implemented on the Sparc, is this: there are two
fp comparision instructions, one (fcmp) signals if either operand is
a signalling NaN, the other (fcmpe) signals if either operand is
a signalling or quiet NaN.

The normal fp comparision operators (<, >, etc) use fcmpe, while 
the ISO routines (isless, isgreater, etc) use fcmp.  Of course they
also use the unordered fbcc insns as well.

If it helps any, Geoff Keating implemented the ISO macros for glibc
like so:

# define __unordered_cmp(x, y) \
  (__extension__                                                              \
   ({ __typeof__(x) __x = (x); __typeof__(y) __y = (y);                       \
      unsigned __r;                                                           \
      __asm__("fcmpu 7,%1,%2 ; mfcr %0" : "=r" (__r) : "f" (__x), "f"(__y)    \
              : "cr7");  \
      __r; }))

# define isgreater(x, y) (__unordered_cmp (x, y) >> 2 & 1)



r~

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: iso c9x unordered fp cmp builtins
  1998-03-01 22:08   ` Richard Henderson
@ 1998-03-01 22:08     ` David Edelsohn
  1998-03-01 22:08       ` Richard Henderson
  0 siblings, 1 reply; 8+ messages in thread
From: David Edelsohn @ 1998-03-01 22:08 UTC (permalink / raw)
  To: Richard Henderson; +Cc: egcs

>>>>> Richard Henderson writes:

Richard> How do these compare with the signalling and quiet NaNs described in
Richard> the IEEE standard?  Are they the same thing with different names?

	These are the signalling and quiet NANs.  I do not have my PowerPC
architecture documents handy to get the terminology exact.

Richard> My understanding is that 

Richard> quiet_nan = 0.0 / 0.0;
Richard> isunordered(quiet_nan, 0.0);

Richard> should return true without killing the program with SIGFPE.

Richard> The way I have it implemented on the Sparc, is this: there are two
Richard> fp comparision instructions, one (fcmp) signals if either operand is
Richard> a signalling NaN, the other (fcmpe) signals if either operand is
Richard> a signalling or quiet NaN.

Richard> The normal fp comparision operators (<, >, etc) use fcmpe, while 
Richard> the ISO routines (isless, isgreater, etc) use fcmp.  Of course they
Richard> also use the unordered fbcc insns as well.

	POWER/PowerPC calls them fcmpu and fcmpo.  The POWER/PowerPC port
of GCC currently follows XLC which only seems to use fcmpu -- quiet NANs
never are signalled.

	Did your SPARC implementation *change* the use of those two FP
compare instructions?

David

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: iso c9x unordered fp cmp builtins
  1998-03-01 22:08     ` David Edelsohn
@ 1998-03-01 22:08       ` Richard Henderson
  1998-03-01 21:52         ` David Edelsohn
       [not found]         ` <9803020551.AA24480.cygnus.egcs@rios1.watson.ibm.com>
  0 siblings, 2 replies; 8+ messages in thread
From: Richard Henderson @ 1998-03-01 22:08 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Richard Henderson, egcs

On Mon, Mar 02, 1998 at 12:34:26AM -0500, David Edelsohn wrote:
> 	POWER/PowerPC calls them fcmpu and fcmpo.  The POWER/PowerPC port
> of GCC currently follows XLC which only seems to use fcmpu -- quiet NANs
> never are signalled.
> 
> 	Did your SPARC implementation *change* the use of those two FP
> compare instructions?

Not with respect to normal comparisions, no.  That is, normal comparisons
do signal qnan, and as far as I can tell, always have.


r~

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: iso c9x unordered fp cmp builtins
  1998-03-01 21:52         ` David Edelsohn
@ 1998-03-01 22:08           ` Richard Henderson
  0 siblings, 0 replies; 8+ messages in thread
From: Richard Henderson @ 1998-03-01 22:08 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Richard Henderson, egcs

On Mon, Mar 02, 1998 at 12:51:22AM -0500, David Edelsohn wrote:
> Does iso9x now mandate that the regular comparison operators signal QNaN?

I don't believe so.

The only thing to do for proper ppc support then is to use whichever
branch it is that tests 

# define isunordered(x, y) (__unordered_cmp (x, y) & 1)

"bun", perhaps?


r~

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: iso c9x unordered fp cmp builtins
       [not found]         ` <9803020551.AA24480.cygnus.egcs@rios1.watson.ibm.com>
@ 1998-03-02 13:08           ` Ulrich Drepper
  0 siblings, 0 replies; 8+ messages in thread
From: Ulrich Drepper @ 1998-03-02 13:08 UTC (permalink / raw)
  To: egcs

dje@watson.ibm.com (David Edelsohn) writes:

> 	The "rs6000" port always has used fcmpu and never has signal QNaN.
> This also is the behavior of IBM's XLC.  Does iso9x now mandate that the
> regular comparison operators signal QNaN?

IEEE 754 and 854 demand this behaviour since the ISO C operators

	==	!=	<	<=	>	>=

are mapped to the IEEE 754 operators (table 4)

	=	?<>	<	<=	>	>=


ISO C 9x defines new functions

	isunordered	isless	islessequal	isgreater	isgreaterequal	islessgreater

which are mapped to the IEEE 754 operators

	?		?<	?<=		?>		?>=		NOT(?)


-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1998-03-02 13:08 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-03-01 18:35 iso c9x unordered fp cmp builtins Richard Henderson
1998-03-01 20:11 ` David Edelsohn
1998-03-01 22:08   ` Richard Henderson
1998-03-01 22:08     ` David Edelsohn
1998-03-01 22:08       ` Richard Henderson
1998-03-01 21:52         ` David Edelsohn
1998-03-01 22:08           ` Richard Henderson
     [not found]         ` <9803020551.AA24480.cygnus.egcs@rios1.watson.ibm.com>
1998-03-02 13:08           ` Ulrich Drepper

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