FP bugs and conditional move

FP bugs and conditional move

[H.J. Lu]

Hi,

Enabling fp constant conditional move in egcs exposes many egcs bugs in
fp constant handling. One bug is fold_rtx () tries to change

(insn 39 38 29 (set (reg:DF 23)
        (if_then_else:DF (ge (cc0)
                (const_int 0))
            (mem/u:DF (symbol_ref/u:SI ("*.LC1")))
            (mem/u:DF (symbol_ref/u:SI ("*.LC0"))))) -1 (nil)
    (nil))

into

(insn 39 38 29 (set (reg:DF 23)
        (if_then_else:DF (ge (cc0)
                (const_int 0))
            (const_double:DF (cc0) 0 0 1073709056)
            (const_double:DF (const_int 0) 0 0 -1073774592))) 380 {movdfcc_1} (nil)
    (nil))

The first one is ok on x87, but not the second one. x87 only allows
a limited number of fp constants which can be loaded into fp
regsiter directly. I believe that may be also true on many other
CPUs. A new macro, IMMEDIATE_CONST_DOUBLE_OK, can be used to
indicate if we can use it as an immediate double constant. On
x87, it is defined as

#define IMMEDIATE_CONST_DOUBLE_OK(V) standard_80387_constant_p(v)

Then we use it in fold_rtx ().

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: FP bugs and conditional move

[Jim Wilson]

	Enabling fp constant conditional move in egcs exposes many egcs bugs in
	fp constant handling. One bug is fold_rtx () tries to change
	... MEMs into CONST_DOUBLEs...

Why is this a problem?  The output of fold_rtx is never used unless it is
a valid instruction for the target, so this should never cause problems.

The output of fold_rtx is used by cse for value tracking, so it is important
to simplify RTL as much as possible.  Also, if we disable it for some cases, we
may find that some optimizations get missed because replacing the MEM with
a CONST_DOUBLE may have allow the expression to be simplified further into
something that was valid.

Jim

Re: FP bugs and conditional move

[H.J. Lu]

> 
> 	Enabling fp constant conditional move in egcs exposes many egcs bugs in
> 	fp constant handling. One bug is fold_rtx () tries to change
> 	... MEMs into CONST_DOUBLEs...
> 
> Why is this a problem?  The output of fold_rtx is never used unless it is
> a valid instruction for the target, so this should never cause problems.
> 
> The output of fold_rtx is used by cse for value tracking, so it is important
> to simplify RTL as much as possible.  Also, if we disable it for some cases, we
> may find that some optimizations get missed because replacing the MEM with
> a CONST_DOUBLE may have allow the expression to be simplified further into
> something that was valid.
> 

I was wrong. But here are some real test cases. Could you pleae verify
them? I have a patch to fix them.

BTW, I have sent my test cases and my patch to Stan.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
Fri Mar 13 08:42:28 1998  H.J. Lu  (hjl@gnu.org)

	* gcc.dg/980313-1.c: New to test fp on PPro.
	* gcc.dg/980313-2.c: Likewise.
	* gcc.dg/980313-3.c: Likewise.
	* gcc.dg/980313-4.c: Likewise.
	* gcc.dg/980313-5.c: Likewise.

--- /dev/null	Wed Dec 31 16:00:00 1969
+++ gcc.dg/980313-1.c	Mon Mar 16 08:47:51 1998
@@ -0,0 +1,21 @@
+/* { dg-do compile { target i?86-*-* } } */
+/* { dg-options "-O2 -march=pentiumpro" } */
+
+extern __inline  double
+__expm1 (double __x)
+{
+  double __temp;
+  __temp -= 1.0;
+  return __temp;
+}
+extern __inline  double
+__sgn1 (double __x)
+{
+  return __x >= 0.0 ? 1.0 : -1.0;
+}
+double
+tanh (double __x)
+{
+  register double __exm1 = __expm1 (__x);
+  return __exm1 / (__exm1 + 2.0) * __sgn1 (-__x);
+}
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ gcc.dg/980313-2.c	Mon Mar 16 09:21:10 1998
@@ -0,0 +1,21 @@
+/* { dg-do compile { target i?86-*-* } } */
+/* { dg-options "-O2 -march=pentiumpro" } */
+
+double
+tanh (double __x)
+{
+  double inline __expm1 (double __x)
+  {
+    double __temp;
+    __temp -= 1.0;
+    return __temp;
+  }
+
+  double inline __sgn1 (double __x)
+  {
+    return __x >= 0.0 ? 1.0 : -1.0;
+  }
+
+  double __exm1 = __expm1 (__x);
+  return __exm1 / (__exm1 + 2.0) * __sgn1 (-__x);
+}
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ gcc.dg/980313-3.c	Mon Mar 16 09:21:42 1998
@@ -0,0 +1,19 @@
+/* { dg-do compile { target i?86-*-* } } */
+/* { dg-options "-O2 -march=pentiumpro" } */
+
+double
+tanh (double __x)
+{
+  double __expm1 (double __x)
+  {
+    double __temp;
+    __temp = 1.0;
+    return __temp;
+  }
+  double __sgn1 (double __x)
+  {
+  return __x >= 0.0 ? 1.0 : -1.0;
+  }
+
+  return  __expm1 (__x) * __sgn1 (-__x);
+}
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ gcc.dg/980313-4.c	Mon Mar 16 09:22:02 1998
@@ -0,0 +1,19 @@
+/* { dg-do compile { target i?86-*-* } } */
+/* { dg-options "-O2 -march=pentiumpro" } */
+
+double
+tanh (double __x)
+{
+  double inline __expm1 (double __x)
+  {
+    double __temp;
+    __temp = 1.0;
+    return __temp;
+  }
+  double  inline __sgn1 (double __x)
+  {
+  return __x >= 0.0 ? 1.0 : -1.0;
+  }
+
+  return  __expm1 (__x) * __sgn1 (-__x);
+}
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ gcc.dg/980313-5.c	Mon Mar 16 08:47:46 1998
@@ -0,0 +1,20 @@
+/* { dg-do compile { target i?86-*-* } } */
+/* { dg-options "-O2 -march=pentiumpro" } */
+
+extern __inline  double
+__expm1 (double __x)
+{
+  double __temp;
+  __temp = 1.0;
+  return __temp;
+}
+extern __inline  double
+__sgn1 (double __x)
+{
+  return __x >= 0.0 ? 1.0 : -1.0;
+}
+double
+tanh (double __x)
+{
+  return  __expm1 (__x) * __sgn1 (-__x);
+}