[PATCH]: Add some more builtins opts for sqrt/cbrt

[PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

This patch adds a few more builtin optimizations for sqrt and cbrt.
The new transformations are:

sqrt(Nroot(x)) -> pow(x,1/(2*N))  (where Nroot is either sqrt or cbrt)
cbrt(N) -> N                      (for N == {0,1,-1})
cbrt(expN(x)) -> expN(x/3)
cbrt(sqrt(x)) -> pow(x,1/6)
cbrt(x)*cbrt(y) -> cbrt(x*y)

I didn't do cbrt(cbrt(x)), cbrt(pow(x,y)) and pow(cbrt(x),y) into
plain pow because I believe all of these would succeed with innocuous
negative values of x but might fail if tranformed into just pow.  I'll
do these later by checking if x is nonnegative or y is a multiple of
three.

Tested on sparc-sun-solaris2.7, no regressions and the new cases pass.

Ok for mainline?

		Thanks,
		--Kaveh


2004-03-12  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* builtins.c (fold_builtin): Add new builtin optimizations for
	sqrt and/or cbrt.
	* fold-const.c (fold): Likewise.

testsuite:
	* gcc.dg/torture/builtin-explog-1.c: Add new cases.
	* gcc.dg/torture/builtin-math-1.c: Likewise.
	* builtin-power-1.c: New test.

diff -rup orig/egcc-CVS20040310/gcc/builtins.c egcc-CVS20040310/gcc/builtins.c
--- orig/egcc-CVS20040310/gcc/builtins.c	2004-03-10 20:02:07.000000000 -0500
+++ egcc-CVS20040310/gcc/builtins.c	2004-03-11 18:03:17.721038000 -0500
@@ -6748,6 +6748,29 @@ fold_builtin (tree exp)
 	      return build_function_call_expr (expfn, arglist);
 	    }
 
+	  /* Optimize sqrt(Nroot(x)) -> pow(x,1/(2*N)).  */
+	  if (flag_unsafe_math_optimizations && BUILTIN_ROOT_P (fcode))
+	    {
+	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+	      
+	      if (powfn)
+	        {
+		  tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+		  tree tree_root;
+		  /* The inner root was either sqrt or cbrt.  */
+		  REAL_VALUE_TYPE dconstroot =
+		    BUILTIN_SQRT_P (fcode) ? dconsthalf : dconstthird;
+		  
+		  /* Adjust for the outer root.  */
+		  dconstroot.exp--;
+		  dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+		  tree_root = build_real (type, dconstroot);
+		  arglist = tree_cons (NULL_TREE, arg0,
+				       build_tree_list (NULL_TREE, tree_root));
+		  return build_function_call_expr (powfn, arglist);
+		}
+	    }
+
 	  /* Optimize sqrt(pow(x,y)) = pow(x,y*0.5).  */
 	  if (flag_unsafe_math_optimizations
 	      && (fcode == BUILT_IN_POW
@@ -6766,6 +6789,56 @@ fold_builtin (tree exp)
 	}
       break;
 
+    case BUILT_IN_CBRT:
+    case BUILT_IN_CBRTF:
+    case BUILT_IN_CBRTL:
+      if (validate_arglist (arglist, REAL_TYPE, VOID_TYPE))
+	{
+	  tree arg = TREE_VALUE (arglist);
+	  const enum built_in_function fcode = builtin_mathfn_code (arg);
+
+	  /* Optimize cbrt of constant value.  */
+	  if (real_zerop (arg) || real_onep (arg) || real_minus_onep (arg))
+	    return arg;
+
+	  /* Optimize cbrt(expN(x)) -> expN(x/3).  */
+	  if (flag_unsafe_math_optimizations && BUILTIN_EXPONENT_P (fcode))
+	    {
+	      tree expfn = TREE_OPERAND (TREE_OPERAND (arg, 0), 0);
+	      const REAL_VALUE_TYPE third_trunc =
+		real_value_truncate (TYPE_MODE (type), dconstthird);
+	      arg = fold (build (MULT_EXPR, type,
+				 TREE_VALUE (TREE_OPERAND (arg, 1)),
+				 build_real (type, third_trunc)));
+	      arglist = build_tree_list (NULL_TREE, arg);
+	      return build_function_call_expr (expfn, arglist);
+	    }
+
+	  /* Optimize cbrt(sqrt(x)) -> pow(x,1/6).  */
+	  /* We don't optimize cbrt(cbrt(x)) -> pow(x,1/9) because if
+             x is negative pow will error but cbrt won't.  */
+	  if (flag_unsafe_math_optimizations && BUILTIN_SQRT_P (fcode))
+	    {
+	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+
+	      if (powfn)
+	        {
+		  tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+		  tree tree_root;
+		  REAL_VALUE_TYPE dconstroot = dconstthird;
+
+		  dconstroot.exp--;
+		  dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+		  tree_root = build_real (type, dconstroot);
+		  arglist = tree_cons (NULL_TREE, arg0,
+				       build_tree_list (NULL_TREE, tree_root));
+		  return build_function_call_expr (powfn, arglist);
+		}
+	      
+	    }
+	}
+      break;
+
     case BUILT_IN_SIN:
     case BUILT_IN_SINF:
     case BUILT_IN_SINL:
diff -rup orig/egcc-CVS20040310/gcc/fold-const.c egcc-CVS20040310/gcc/fold-const.c
--- orig/egcc-CVS20040310/gcc/fold-const.c	2004-03-10 13:13:01.000000000 -0500
+++ egcc-CVS20040310/gcc/fold-const.c	2004-03-11 13:17:27.744332000 -0500
@@ -6422,23 +6422,24 @@ fold (tree expr)
 	      enum built_in_function fcode0 = builtin_mathfn_code (arg0);
 	      enum built_in_function fcode1 = builtin_mathfn_code (arg1);
 
-	      /* Optimizations of sqrt(...)*sqrt(...).  */
-	      if (fcode0 == fcode1 && BUILTIN_SQRT_P (fcode0))
+	      /* Optimizations of root(...)*root(...).  */
+	      if (fcode0 == fcode1 && BUILTIN_ROOT_P (fcode0))
 		{
-		  tree sqrtfn, arg, arglist;
+		  tree rootfn, arg, arglist;
 		  tree arg00 = TREE_VALUE (TREE_OPERAND (arg0, 1));
 		  tree arg10 = TREE_VALUE (TREE_OPERAND (arg1, 1));
 
 		  /* Optimize sqrt(x)*sqrt(x) as x.  */
-		  if (operand_equal_p (arg00, arg10, 0)
+		  if (BUILTIN_SQRT_P (fcode0)
+		      && operand_equal_p (arg00, arg10, 0)
 		      && ! HONOR_SNANS (TYPE_MODE (type)))
 		    return arg00;
 
-	          /* Optimize sqrt(x)*sqrt(y) as sqrt(x*y).  */
-		  sqrtfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
+	          /* Optimize root(x)*root(y) as root(x*y).  */
+		  rootfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
 		  arg = fold (build (MULT_EXPR, type, arg00, arg10));
 		  arglist = build_tree_list (NULL_TREE, arg);
-		  return build_function_call_expr (sqrtfn, arglist);
+		  return build_function_call_expr (rootfn, arglist);
 		}
 
 	      /* Optimize expN(x)*expN(y) as expN(x+y).  */
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c	2004-03-06 12:53:57.000000000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c	2004-03-11 18:56:30.834742000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2003  Free Software Foundation.
+/* Copyright (C) 2003, 2004  Free Software Foundation.
 
    Verify that built-in math function constant folding of log & exp is
    correctly performed by the compiler.
@@ -119,6 +119,17 @@ void test(double d1, double d2, float f1
   LOG_CBRT(log2);
   LOG_CBRT(log10);
   
+  /* Test cbrt(expN(x)) -> expN(x/3).  */
+#define CBRT_EXP(EXP) \
+ extern void link_failure_cbrt_##EXP(void); \
+ if (cbrt(EXP(d1)) != EXP(d1/3.0) || cbrtf(EXP##f(f1)) != EXP##f(f1/3.0F) \
+  || cbrtl(EXP##l(ld1)) != EXP##l(ld1/3.0L)) link_failure_cbrt_##EXP()
+    
+  CBRT_EXP(exp);
+  CBRT_EXP(exp2);
+  CBRT_EXP(exp10);
+  CBRT_EXP(pow10);
+  
   /* Test logN(pow(x,y)) -> y*logN(x).  */
 #define LOG_POW(LOG, POW) \
  extern void link_failure_##LOG##_##POW(void); \
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c	2003-08-02 15:09:54.000000000 -0400
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c	2004-03-11 18:56:25.215208000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2002, 2003  Free Software Foundation.
+/* Copyright (C) 2002, 2003, 2004  Free Software Foundation.
 
    Verify that built-in math function constant folding of constant
    arguments is correctly performed by the compiler.
@@ -18,6 +18,15 @@ void test (float f, double d, long doubl
   if (sqrt (1.0) != 1.0)
     link_error ();
 
+  if (cbrt (0.0) != 0.0)
+    link_error ();
+
+  if (cbrt (1.0) != 1.0)
+    link_error ();
+
+  if (cbrt (-1.0) != -1.0)
+    link_error ();
+
   if (exp (0.0) != 1.0)
     link_error ();
 
@@ -55,6 +64,15 @@ void test (float f, double d, long doubl
   if (sqrtf (1.0F) != 1.0F)
     link_error ();
 
+  if (cbrtf (0.0F) != 0.0F)
+    link_error ();
+
+  if (cbrtf (1.0F) != 1.0F)
+    link_error ();
+
+  if (cbrtf (-1.0F) != -1.0F)
+    link_error ();
+
   if (expf (0.0F) != 1.0F)
     link_error ();
 
@@ -92,6 +110,15 @@ void test (float f, double d, long doubl
   if (sqrtl (1.0L) != 1.0L)
     link_error ();
 
+  if (cbrtl (0.0L) != 0.0L)
+    link_error ();
+
+  if (cbrtl (1.0L) != 1.0L)
+    link_error ();
+
+  if (cbrtl (-1.0L) != -1.0L)
+    link_error ();
+
   if (expl (0.0L) != 1.0L)
     link_error ();
 
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c	2004-03-11 18:14:10.341709000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c	2004-03-11 18:56:03.906846000 -0500
@@ -0,0 +1,105 @@
+/* Copyright (C) 2004  Free Software Foundation.
+
+   Verify that built-in folding of various math "power" functions is
+   correctly performed by the compiler.
+
+   Written by Kaveh Ghazi, 2004-03-11.  */
+
+/* { dg-do link } */
+/* { dg-options "-ffast-math" } */
+
+#include "../builtins-config.h"
+
+#ifdef HAVE_C99_RUNTIME
+#define C99CODE(CODE) CODE
+#else
+#define C99CODE(CODE) 0
+#endif
+
+#define PROTOTYPE(FN) extern double FN(double); extern float FN##f(float); \
+  extern long double FN##l(long double);
+#define PROTOTYPE2(FN) extern double FN(double, double); \
+  extern float FN##f(float, float); \
+  extern long double FN##l(long double, long double);
+
+PROTOTYPE(sqrt)
+PROTOTYPE(cbrt)
+PROTOTYPE2(pow)
+
+void test(double d1, double d2, double d3,
+	  float f1, float f2, float f3,
+	  long double ld1, long double ld2, long double ld3)
+{
+  /* Test N1root(N2root(x)) -> pow(x,1/(N1*N2)).  */
+  /* E.g. sqrt(cbrt(x)) -> pow(x,1/6).  */
+#define ROOT_ROOT(FN1,N1,FN2,N2) \
+ extern void link_failure_##FN1##_##FN2(void); \
+ if (FN1(FN2(d1)) != pow(d1,1.0/(N1*N2)) \
+     || C99CODE (FN1##f(FN2##f(f1)) != powf(f1,1.0F/(N1*N2))) \
+     || C99CODE (FN1##l(FN2##l(ld1)) != powl(ld1,1.0L/(N1*N2)))) \
+    link_failure_##FN1##_##FN2()
+
+  ROOT_ROOT(sqrt,2,sqrt,2);
+  ROOT_ROOT(sqrt,2,cbrt,3);
+  ROOT_ROOT(cbrt,3,sqrt,2);
+  /*ROOT_ROOT(cbrt,3,cbrt,3); Intentionally not implemented.  */
+
+  /* Test pow(Nroot(x),y) -> pow(x,y/N).  */
+#define POW_ROOT(FN,N) \
+ extern void link_failure_pow_##FN(void); \
+ if (pow(FN(d1), d2) != pow(d1,d2/N) \
+     || powf(FN##f(f1),f2) != powf(f1,f2/N) \
+     || powl(FN##l(ld1),ld2) != powl(ld1,ld2/N)) \
+    link_failure_pow_##FN()
+
+  POW_ROOT(sqrt,2);
+  /*POW_ROOT(cbrt,3); Intentionally not implemented.  */
+
+  /* Test Nroot(pow(x,y)) -> pow(x,y/N).  */
+#define ROOT_POW(FN,N) \
+ extern void link_failure_##FN##_pow(void); \
+ if (FN(pow(d1, d2)) != pow(d1,d2/N) \
+     || FN##f(powf(f1,f2)) != powf(f1,f2/N) \
+     || FN##l(powl(ld1,ld2)) != powl(ld1,ld2/N)) \
+    link_failure_##FN##_pow()
+
+  ROOT_POW(sqrt,2);
+  /*ROOT_POW(cbrt,3); Intentionally not implemented.  */
+
+  /* Test pow(pow(x,y),z) -> pow(x,y*z).  */
+#define POW_POW \
+ extern void link_failure_pow_pow(void); \
+ if (pow(pow(d1, d2), d3) != pow(d1,d2*d3) \
+     || powf(powf(f1,f2),f3) != powf(f1,f2*f3) \
+     || powl(powl(ld1,ld2),ld3) != powl(ld1,ld2*ld3)) \
+    link_failure_pow_pow()
+
+  POW_POW;
+
+  /* Test Nroot(x)*Nroot(y) -> Nroot(x*y).  */
+#define ROOT_X_ROOT(FN) \
+ extern void link_failure_root_x_root(void); \
+ if (FN(d1)*FN(d2) != FN(d1*d2) \
+     || FN##f(f1)*FN##f(f2) != FN##f(f1*f2) \
+     || FN##l(ld1)*FN##l(ld2) != FN##l(ld1*ld2)) \
+    link_failure_root_x_root()
+
+  ROOT_X_ROOT(sqrt);
+  ROOT_X_ROOT(cbrt);
+  
+  /* Test pow(x,y)*pow(x,z) -> pow(x,y+z).  */
+#define POW_X_POW \
+ extern void link_failure_pow_x_pow(void); \
+ if (pow(d1,d2)*pow(d1,d3) != pow(d1,d2+d3) \
+     || powf(f1,f2)*powf(f1,f3) != powf(f1,f2+f3) \
+     || powl(ld1,ld2)*powl(ld1,ld3) != powl(ld1,ld2+ld3)) \
+    link_failure_pow_x_pow()
+
+  POW_X_POW;
+  
+}
+
+int main (void)
+{
+  return 0;
+}

[PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

This patch adds a few more builtin optimizations for sqrt and cbrt.
The new transformations are:

sqrt(Nroot(x)) -> pow(x,1/(2*N))  (where Nroot is either sqrt or cbrt)
cbrt(N) -> N                      (for N == {0,1,-1})
cbrt(expN(x)) -> expN(x/3)
cbrt(sqrt(x)) -> pow(x,1/6)
cbrt(x)*cbrt(y) -> cbrt(x*y)

I didn't do cbrt(cbrt(x)), cbrt(pow(x,y)) and pow(cbrt(x),y) into
plain pow because I believe all of these would succeed with innocuous
negative values of x but might fail if tranformed into just pow.  I'll
do these later by checking if x is nonnegative or y is a multiple of
three.

Tested on sparc-sun-solaris2.7, no regressions and the new cases pass.

Ok for mainline?

		Thanks,
		--Kaveh


2004-03-12  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* builtins.c (fold_builtin): Add new builtin optimizations for
	sqrt and/or cbrt.
	* fold-const.c (fold): Likewise.

testsuite:
	* gcc.dg/torture/builtin-explog-1.c: Add new cases.
	* gcc.dg/torture/builtin-math-1.c: Likewise.
	* builtin-power-1.c: New test.

diff -rup orig/egcc-CVS20040310/gcc/builtins.c egcc-CVS20040310/gcc/builtins.c
--- orig/egcc-CVS20040310/gcc/builtins.c	2004-03-10 20:02:07.000000000 -0500
+++ egcc-CVS20040310/gcc/builtins.c	2004-03-11 18:03:17.721038000 -0500
@@ -6748,6 +6748,29 @@ fold_builtin (tree exp)
 	      return build_function_call_expr (expfn, arglist);
 	    }
 
+	  /* Optimize sqrt(Nroot(x)) -> pow(x,1/(2*N)).  */
+	  if (flag_unsafe_math_optimizations && BUILTIN_ROOT_P (fcode))
+	    {
+	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+	      
+	      if (powfn)
+	        {
+		  tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+		  tree tree_root;
+		  /* The inner root was either sqrt or cbrt.  */
+		  REAL_VALUE_TYPE dconstroot =
+		    BUILTIN_SQRT_P (fcode) ? dconsthalf : dconstthird;
+		  
+		  /* Adjust for the outer root.  */
+		  dconstroot.exp--;
+		  dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+		  tree_root = build_real (type, dconstroot);
+		  arglist = tree_cons (NULL_TREE, arg0,
+				       build_tree_list (NULL_TREE, tree_root));
+		  return build_function_call_expr (powfn, arglist);
+		}
+	    }
+
 	  /* Optimize sqrt(pow(x,y)) = pow(x,y*0.5).  */
 	  if (flag_unsafe_math_optimizations
 	      && (fcode == BUILT_IN_POW
@@ -6766,6 +6789,56 @@ fold_builtin (tree exp)
 	}
       break;
 
+    case BUILT_IN_CBRT:
+    case BUILT_IN_CBRTF:
+    case BUILT_IN_CBRTL:
+      if (validate_arglist (arglist, REAL_TYPE, VOID_TYPE))
+	{
+	  tree arg = TREE_VALUE (arglist);
+	  const enum built_in_function fcode = builtin_mathfn_code (arg);
+
+	  /* Optimize cbrt of constant value.  */
+	  if (real_zerop (arg) || real_onep (arg) || real_minus_onep (arg))
+	    return arg;
+
+	  /* Optimize cbrt(expN(x)) -> expN(x/3).  */
+	  if (flag_unsafe_math_optimizations && BUILTIN_EXPONENT_P (fcode))
+	    {
+	      tree expfn = TREE_OPERAND (TREE_OPERAND (arg, 0), 0);
+	      const REAL_VALUE_TYPE third_trunc =
+		real_value_truncate (TYPE_MODE (type), dconstthird);
+	      arg = fold (build (MULT_EXPR, type,
+				 TREE_VALUE (TREE_OPERAND (arg, 1)),
+				 build_real (type, third_trunc)));
+	      arglist = build_tree_list (NULL_TREE, arg);
+	      return build_function_call_expr (expfn, arglist);
+	    }
+
+	  /* Optimize cbrt(sqrt(x)) -> pow(x,1/6).  */
+	  /* We don't optimize cbrt(cbrt(x)) -> pow(x,1/9) because if
+             x is negative pow will error but cbrt won't.  */
+	  if (flag_unsafe_math_optimizations && BUILTIN_SQRT_P (fcode))
+	    {
+	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+
+	      if (powfn)
+	        {
+		  tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+		  tree tree_root;
+		  REAL_VALUE_TYPE dconstroot = dconstthird;
+
+		  dconstroot.exp--;
+		  dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+		  tree_root = build_real (type, dconstroot);
+		  arglist = tree_cons (NULL_TREE, arg0,
+				       build_tree_list (NULL_TREE, tree_root));
+		  return build_function_call_expr (powfn, arglist);
+		}
+	      
+	    }
+	}
+      break;
+
     case BUILT_IN_SIN:
     case BUILT_IN_SINF:
     case BUILT_IN_SINL:
diff -rup orig/egcc-CVS20040310/gcc/fold-const.c egcc-CVS20040310/gcc/fold-const.c
--- orig/egcc-CVS20040310/gcc/fold-const.c	2004-03-10 13:13:01.000000000 -0500
+++ egcc-CVS20040310/gcc/fold-const.c	2004-03-11 13:17:27.744332000 -0500
@@ -6422,23 +6422,24 @@ fold (tree expr)
 	      enum built_in_function fcode0 = builtin_mathfn_code (arg0);
 	      enum built_in_function fcode1 = builtin_mathfn_code (arg1);
 
-	      /* Optimizations of sqrt(...)*sqrt(...).  */
-	      if (fcode0 == fcode1 && BUILTIN_SQRT_P (fcode0))
+	      /* Optimizations of root(...)*root(...).  */
+	      if (fcode0 == fcode1 && BUILTIN_ROOT_P (fcode0))
 		{
-		  tree sqrtfn, arg, arglist;
+		  tree rootfn, arg, arglist;
 		  tree arg00 = TREE_VALUE (TREE_OPERAND (arg0, 1));
 		  tree arg10 = TREE_VALUE (TREE_OPERAND (arg1, 1));
 
 		  /* Optimize sqrt(x)*sqrt(x) as x.  */
-		  if (operand_equal_p (arg00, arg10, 0)
+		  if (BUILTIN_SQRT_P (fcode0)
+		      && operand_equal_p (arg00, arg10, 0)
 		      && ! HONOR_SNANS (TYPE_MODE (type)))
 		    return arg00;
 
-	          /* Optimize sqrt(x)*sqrt(y) as sqrt(x*y).  */
-		  sqrtfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
+	          /* Optimize root(x)*root(y) as root(x*y).  */
+		  rootfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
 		  arg = fold (build (MULT_EXPR, type, arg00, arg10));
 		  arglist = build_tree_list (NULL_TREE, arg);
-		  return build_function_call_expr (sqrtfn, arglist);
+		  return build_function_call_expr (rootfn, arglist);
 		}
 
 	      /* Optimize expN(x)*expN(y) as expN(x+y).  */
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c	2004-03-06 12:53:57.000000000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c	2004-03-11 18:56:30.834742000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2003  Free Software Foundation.
+/* Copyright (C) 2003, 2004  Free Software Foundation.
 
    Verify that built-in math function constant folding of log & exp is
    correctly performed by the compiler.
@@ -119,6 +119,17 @@ void test(double d1, double d2, float f1
   LOG_CBRT(log2);
   LOG_CBRT(log10);
   
+  /* Test cbrt(expN(x)) -> expN(x/3).  */
+#define CBRT_EXP(EXP) \
+ extern void link_failure_cbrt_##EXP(void); \
+ if (cbrt(EXP(d1)) != EXP(d1/3.0) || cbrtf(EXP##f(f1)) != EXP##f(f1/3.0F) \
+  || cbrtl(EXP##l(ld1)) != EXP##l(ld1/3.0L)) link_failure_cbrt_##EXP()
+    
+  CBRT_EXP(exp);
+  CBRT_EXP(exp2);
+  CBRT_EXP(exp10);
+  CBRT_EXP(pow10);
+  
   /* Test logN(pow(x,y)) -> y*logN(x).  */
 #define LOG_POW(LOG, POW) \
  extern void link_failure_##LOG##_##POW(void); \
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c	2003-08-02 15:09:54.000000000 -0400
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c	2004-03-11 18:56:25.215208000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2002, 2003  Free Software Foundation.
+/* Copyright (C) 2002, 2003, 2004  Free Software Foundation.
 
    Verify that built-in math function constant folding of constant
    arguments is correctly performed by the compiler.
@@ -18,6 +18,15 @@ void test (float f, double d, long doubl
   if (sqrt (1.0) != 1.0)
     link_error ();
 
+  if (cbrt (0.0) != 0.0)
+    link_error ();
+
+  if (cbrt (1.0) != 1.0)
+    link_error ();
+
+  if (cbrt (-1.0) != -1.0)
+    link_error ();
+
   if (exp (0.0) != 1.0)
     link_error ();
 
@@ -55,6 +64,15 @@ void test (float f, double d, long doubl
   if (sqrtf (1.0F) != 1.0F)
     link_error ();
 
+  if (cbrtf (0.0F) != 0.0F)
+    link_error ();
+
+  if (cbrtf (1.0F) != 1.0F)
+    link_error ();
+
+  if (cbrtf (-1.0F) != -1.0F)
+    link_error ();
+
   if (expf (0.0F) != 1.0F)
     link_error ();
 
@@ -92,6 +110,15 @@ void test (float f, double d, long doubl
   if (sqrtl (1.0L) != 1.0L)
     link_error ();
 
+  if (cbrtl (0.0L) != 0.0L)
+    link_error ();
+
+  if (cbrtl (1.0L) != 1.0L)
+    link_error ();
+
+  if (cbrtl (-1.0L) != -1.0L)
+    link_error ();
+
   if (expl (0.0L) != 1.0L)
     link_error ();
 
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c	2004-03-11 18:14:10.341709000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c	2004-03-11 18:56:03.906846000 -0500
@@ -0,0 +1,105 @@
+/* Copyright (C) 2004  Free Software Foundation.
+
+   Verify that built-in folding of various math "power" functions is
+   correctly performed by the compiler.
+
+   Written by Kaveh Ghazi, 2004-03-11.  */
+
+/* { dg-do link } */
+/* { dg-options "-ffast-math" } */
+
+#include "../builtins-config.h"
+
+#ifdef HAVE_C99_RUNTIME
+#define C99CODE(CODE) CODE
+#else
+#define C99CODE(CODE) 0
+#endif
+
+#define PROTOTYPE(FN) extern double FN(double); extern float FN##f(float); \
+  extern long double FN##l(long double);
+#define PROTOTYPE2(FN) extern double FN(double, double); \
+  extern float FN##f(float, float); \
+  extern long double FN##l(long double, long double);
+
+PROTOTYPE(sqrt)
+PROTOTYPE(cbrt)
+PROTOTYPE2(pow)
+
+void test(double d1, double d2, double d3,
+	  float f1, float f2, float f3,
+	  long double ld1, long double ld2, long double ld3)
+{
+  /* Test N1root(N2root(x)) -> pow(x,1/(N1*N2)).  */
+  /* E.g. sqrt(cbrt(x)) -> pow(x,1/6).  */
+#define ROOT_ROOT(FN1,N1,FN2,N2) \
+ extern void link_failure_##FN1##_##FN2(void); \
+ if (FN1(FN2(d1)) != pow(d1,1.0/(N1*N2)) \
+     || C99CODE (FN1##f(FN2##f(f1)) != powf(f1,1.0F/(N1*N2))) \
+     || C99CODE (FN1##l(FN2##l(ld1)) != powl(ld1,1.0L/(N1*N2)))) \
+    link_failure_##FN1##_##FN2()
+
+  ROOT_ROOT(sqrt,2,sqrt,2);
+  ROOT_ROOT(sqrt,2,cbrt,3);
+  ROOT_ROOT(cbrt,3,sqrt,2);
+  /*ROOT_ROOT(cbrt,3,cbrt,3); Intentionally not implemented.  */
+
+  /* Test pow(Nroot(x),y) -> pow(x,y/N).  */
+#define POW_ROOT(FN,N) \
+ extern void link_failure_pow_##FN(void); \
+ if (pow(FN(d1), d2) != pow(d1,d2/N) \
+     || powf(FN##f(f1),f2) != powf(f1,f2/N) \
+     || powl(FN##l(ld1),ld2) != powl(ld1,ld2/N)) \
+    link_failure_pow_##FN()
+
+  POW_ROOT(sqrt,2);
+  /*POW_ROOT(cbrt,3); Intentionally not implemented.  */
+
+  /* Test Nroot(pow(x,y)) -> pow(x,y/N).  */
+#define ROOT_POW(FN,N) \
+ extern void link_failure_##FN##_pow(void); \
+ if (FN(pow(d1, d2)) != pow(d1,d2/N) \
+     || FN##f(powf(f1,f2)) != powf(f1,f2/N) \
+     || FN##l(powl(ld1,ld2)) != powl(ld1,ld2/N)) \
+    link_failure_##FN##_pow()
+
+  ROOT_POW(sqrt,2);
+  /*ROOT_POW(cbrt,3); Intentionally not implemented.  */
+
+  /* Test pow(pow(x,y),z) -> pow(x,y*z).  */
+#define POW_POW \
+ extern void link_failure_pow_pow(void); \
+ if (pow(pow(d1, d2), d3) != pow(d1,d2*d3) \
+     || powf(powf(f1,f2),f3) != powf(f1,f2*f3) \
+     || powl(powl(ld1,ld2),ld3) != powl(ld1,ld2*ld3)) \
+    link_failure_pow_pow()
+
+  POW_POW;
+
+  /* Test Nroot(x)*Nroot(y) -> Nroot(x*y).  */
+#define ROOT_X_ROOT(FN) \
+ extern void link_failure_root_x_root(void); \
+ if (FN(d1)*FN(d2) != FN(d1*d2) \
+     || FN##f(f1)*FN##f(f2) != FN##f(f1*f2) \
+     || FN##l(ld1)*FN##l(ld2) != FN##l(ld1*ld2)) \
+    link_failure_root_x_root()
+
+  ROOT_X_ROOT(sqrt);
+  ROOT_X_ROOT(cbrt);
+  
+  /* Test pow(x,y)*pow(x,z) -> pow(x,y+z).  */
+#define POW_X_POW \
+ extern void link_failure_pow_x_pow(void); \
+ if (pow(d1,d2)*pow(d1,d3) != pow(d1,d2+d3) \
+     || powf(f1,f2)*powf(f1,f3) != powf(f1,f2+f3) \
+     || powl(ld1,ld2)*powl(ld1,ld3) != powl(ld1,ld2+ld3)) \
+    link_failure_pow_x_pow()
+
+  POW_X_POW;
+  
+}
+
+int main (void)
+{
+  return 0;
+}

Unreviewed patch

[Kaveh R. Ghazi]

It's been around two weeks since I posted this patch:

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01033.html

Would someone please review it?  It would be much appreciated.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Unreviewed patch

[Roger Sayle]

On Thu, 25 Mar 2004, Kaveh R. Ghazi wrote:
> It's been around two weeks since I posted this patch:
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01033.html

This is Ok for mainline.

Roger
--

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[David Edelsohn]

	builtin-power-1.c is failing on PowerPC.  On AIX I see the
following link failures in the log:

ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_sqrt
ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_cbrt
ld: 0711-317 ERROR: Undefined symbol: .link_failure_cbrt_sqrt

It also is failing on Darwin, along with other builtins.

David

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: David Edelsohn <dje@watson.ibm.com>
 > 
 > 	builtin-power-1.c is failing on PowerPC.  On AIX I see the
 > following link failures in the log:
 > 
 > ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_sqrt
 > ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_cbrt
 > ld: 0711-317 ERROR: Undefined symbol: .link_failure_cbrt_sqrt

The problem here was that we were transforming into the wrong FP type,
i.e. pow vs powl.  The following patch seems to fix the problem in a
cross config to aix5.1 when visually scanning the assembly output.

David - Does it fix the failure you saw?

Meanwhile, I'm running a full regression test on solaris2.7.  Assuming
it fixes David's failure and passes regtest, ok for mainline?

		--Kaveh

PS: I indended to use `mathfn_built_in' to say "give me the mathfn
builtin for a particular FP type, e.g. float".  It doesn't appear to
do that exactly, so I'm not sure when it's ever correct to use
mathfn_built_in.



2004-03-27  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* builtins.c (fold_builtin): Don't use `mathfn_built_in' to lookup
	replacement builtin.

diff -rup orig/egcc-CVS20040327/gcc/builtins.c egcc-CVS20040327/gcc/builtins.c
--- orig/egcc-CVS20040327/gcc/builtins.c	Thu Mar 25 19:27:52 2004
+++ egcc-CVS20040327/gcc/builtins.c	Sat Mar 27 18:45:44 2004
@@ -6693,7 +6693,12 @@ fold_builtin (tree exp)
 	  /* Optimize sqrt(Nroot(x)) -> pow(x,1/(2*N)).  */
 	  if (flag_unsafe_math_optimizations && BUILTIN_ROOT_P (fcode))
 	    {
-	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+	      tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRT)
+		? implicit_built_in_decls[BUILT_IN_POW] :
+		(DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRTF)
+		? implicit_built_in_decls[BUILT_IN_POWF] :
+		(DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRTL)
+		? implicit_built_in_decls[BUILT_IN_POWL] : NULL_TREE;
 	      
 	      if (powfn)
 	        {
@@ -6761,7 +6766,12 @@ fold_builtin (tree exp)
              x is negative pow will error but cbrt won't.  */
 	  if (flag_unsafe_math_optimizations && BUILTIN_SQRT_P (fcode))
 	    {
-	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+	      tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CBRT)
+		? implicit_built_in_decls[BUILT_IN_POW] :
+		(DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CBRTF)
+		? implicit_built_in_decls[BUILT_IN_POWF] :
+		(DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CBRTL)
+		? implicit_built_in_decls[BUILT_IN_POWL] : NULL_TREE;
 
 	      if (powfn)
 	        {

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: David Edelsohn <dje@watson.ibm.com>
 > 
 > 	builtin-power-1.c is failing on PowerPC.  [...]
 > 
 > It also is failing on Darwin, along with other builtins.
 > David

The darwin failure is different.  It occurs because there is a
mismatch in whether GCC thinks darwin has C99 functions between the
darwin port itself and the testsuite.  Fixing this will correct much
more than just builtin-power-1.c.  As you noted, there are several
builtins failures on darwin.

If darwin has the C99 functions, then someone needs to add
#define TARGET_C99_FUNCTIONS 1
to config/darwin.h.

If darwin doesn't have the C99 functions, then someone needs to tweek
testsuite/gcc.dg/builtins-config.h appropriately so darwin doesn't
attempt to test any transformations which result in C99 function
calls.

Either way, someone who knows darwin and can test on it should fix
this.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[David Edelsohn]

>>>>> Kaveh R Ghazi writes:

Kaveh> The problem here was that we were transforming into the wrong FP type,
Kaveh> i.e. pow vs powl.  The following patch seems to fix the problem in a
Kaveh> cross config to aix5.1 when visually scanning the assembly output.

Kaveh> David - Does it fix the failure you saw?

	Yes, the patch fixes the failures I am seeing on AIX.

Thanks, David

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Andrew Pinski]

On Mar 27, 2004, at 19:11, Kaveh R. Ghazi wrote:

>> From: David Edelsohn <dje@watson.ibm.com>
>>
>> 	builtin-power-1.c is failing on PowerPC.  [...]
>>
>> It also is failing on Darwin, along with other builtins.
>> David
>
> The darwin failure is different.  It occurs because there is a
> mismatch in whether GCC thinks darwin has C99 functions between the
> darwin port itself and the testsuite.  Fixing this will correct much
> more than just builtin-power-1.c.  As you noted, there are several
> builtins failures on darwin.
>
> If darwin has the C99 functions, then someone needs to add
> #define TARGET_C99_FUNCTIONS 1
> to config/darwin.h.
>
> If darwin doesn't have the C99 functions, then someone needs to tweek
> testsuite/gcc.dg/builtins-config.h appropriately so darwin doesn't
> attempt to test any transformations which result in C99 function
> calls.
>
> Either way, someone who knows darwin and can test on it should fix
> this.

I have a fix for darwin but I have not applied it yet, I have been
just to busy to finish it up as the C99 math functions are in the
libmx library which causes so much problems.  I have already fixed
libgfortran to support this library but I need to add support for
libstdc++.

I am almost ready to file a bug (with Apple) asking for the
functions to be in libm or libsystem as that makes it more
consistent with the rest of the UNIX world.

Thanks,
Andrew Pinski

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: Andrew Pinski <pinskia@physics.uc.edu>
 > 
 > On Mar 27, 2004, at 19:11, Kaveh R. Ghazi wrote:
 > 
 > > If darwin has the C99 functions, then someone needs to add
 > > #define TARGET_C99_FUNCTIONS 1
 > > to config/darwin.h.
 > >
 > > If darwin doesn't have the C99 functions, then someone needs to tweek
 > > testsuite/gcc.dg/builtins-config.h appropriately so darwin doesn't
 > > attempt to test any transformations which result in C99 function
 > > calls.
 > >
 > > Either way, someone who knows darwin and can test on it should fix
 > > this.
 > 
 > I have a fix for darwin but I have not applied it yet, I have been
 > just to busy to finish it up as the C99 math functions are in the
 > libmx library which causes so much problems.  I have already fixed
 > libgfortran to support this library but I need to add support for
 > libstdc++.
 > 
 > I am almost ready to file a bug (with Apple) asking for the
 > functions to be in libm or libsystem as that makes it more
 > consistent with the rest of the UNIX world.

Ok, thanks for the info.  In the mean time, perhaps you would like to
add a darwin bypass into builtins-config.h to reduce the testsuite
noise there?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Richard Henderson]

On Sat, Mar 27, 2004 at 07:05:32PM -0500, Kaveh R. Ghazi wrote:
> -	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
> +	      tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRT)
> +		? implicit_built_in_decls[BUILT_IN_POW] :
...

This would suggest that TYPE is wrong in that call then.



r~

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > On Sat, Mar 27, 2004 at 07:05:32PM -0500, Kaveh R. Ghazi wrote:
 > > -	      tree powfn = mathfn_built_in (type, BUILT_IN_POW);
 > > +	      tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRT)
 > > +		? implicit_built_in_decls[BUILT_IN_POW] :
 > ...
 > 
 > This would suggest that TYPE is wrong in that call then.
 > r~

No, I don't think so.

I did some further investigating as to why mathfn_built_in didn't do
what I expected.  The code in the function says:

  const enum machine_mode type_mode = TYPE_MODE (type);
  [...]
  if (type_mode == TYPE_MODE (double_type_node))
    return implicit_built_in_decls[fcode];
  else if (type_mode == TYPE_MODE (float_type_node))
    return implicit_built_in_decls[fcodef];
  else if (type_mode == TYPE_MODE (long_double_type_node))
    return implicit_built_in_decls[fcodel];
  else
    return 0;

If I understand it correctly, there's no guarantee that if you ask for
a "long double" pow function that you'll actually get `powl'.  The
code prefers the "double" version if the sizes of double and long
double are equal (as I believe they are on aix5 where the error
appeared.)

I'm not sure this is the best design for `mathfn_built_in'.  At least,
it wasn't intuitive to me.

Thoughts?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Richard Henderson]

On Mon, Mar 29, 2004 at 03:47:17PM -0500, Kaveh R. Ghazi wrote:
> If I understand it correctly, there's no guarantee that if you ask for
> a "long double" pow function that you'll actually get `powl'.

That's also a bug.  Why are we comparing modes as opposed
to type-main-variant or such?


r~

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > On Mon, Mar 29, 2004 at 03:47:17PM -0500, Kaveh R. Ghazi wrote:
 > > If I understand it correctly, there's no guarantee that if you ask for
 > > a "long double" pow function that you'll actually get `powl'.
 > 
 > That's also a bug.  Why are we comparing modes as opposed
 > to type-main-variant or such?
 > r~

Don't know, let's ask the original author of the function.  Jan?

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: David Edelsohn <dje@watson.ibm.com>
 > 
 > >>>>> Kaveh R Ghazi writes:
 > 
 > Kaveh> Yes a patch went in around three weeks ago, are you still seeing a
 > Kaveh> problem?  Didn't you confirm the patch fixed the AIX5 failures? :-)
 > 
 > Kaveh> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00596.html
 > Kaveh> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00601.html
 > 
 > 	I guess I expected the builtin problems on the Tree-SSA branch
 > to improve as well after that patch was merged into the branch.  I
 > still see numerous failures there.
 > David

My understanding is that those failures are an entirely different and
systemic problem that builtins have with SSA form and it won't be
solved until after the merge.  See:

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01003.html
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01023.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[David Edelsohn]

>>>>> Kaveh R Ghazi writes:

Kaveh> Yes a patch went in around three weeks ago, are you still seeing a
Kaveh> problem?  Didn't you confirm the patch fixed the AIX5 failures? :-)

Kaveh> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00596.html
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00601.html

	I guess I expected the builtin problems on the Tree-SSA branch to
improve as well after that patch was merged into the branch.  I still see
numerous failures there.

David

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: David Edelsohn <dje@watson.ibm.com>
 > 
 > >> If we have no reason to keep the mathfn_built_in algorithm this way,
 > >> I'd like to change it to return predictable values regardless of the
 > >> sizes of the FP types on the target.
 > 
 > >That sounds fine to me.
 > 
 > 	Any progress on reaching a consensus to fix the testsuite
 > failures and implementing the solution?
 > Thanks, David

Yes a patch went in around three weeks ago, are you still seeing a
problem?  Didn't you confirm the patch fixed the AIX5 failures? :-)

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00596.html
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00601.html

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[David Edelsohn]

>> If we have no reason to keep the mathfn_built_in algorithm this way,
>> I'd like to change it to return predictable values regardless of the
>> sizes of the FP types on the target.

>That sounds fine to me.

	Any progress on reaching a consensus to fix the testsuite failures
and implementing the solution?

Thanks, David

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[John David Anglin]

> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.

This might be the best approach.  There are also about a half-dozen
`long double' related testsuite failures on hppa-linux in the libstdc++
suite.  These might also be caused by the above uncertainty.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
 > 
 > The following tests are failing under hppa-unknown-linux-gnu:
 > 
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O0  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O1  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O2  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -fomit-frame-pointer  (test for exce
 > ss errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -g  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -Os  (test for excess errors)
 > 
 > On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
 > the same size (as defined in defaults.h).  It has C99 functions.
 > 
 > I removed the long double tests from builtin-power-1.c and the tests
 > then pass.  I think this points to a problem with the builtins when two
 > types (double and long double) have the same size.

Yes, I know about this one.  See
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html

The discussion died off waiting for an explanation from Jan about
mathfn_built_in.

This failure is harmless from a code correctness standpoint.  It's
simply that when sizeof double and long double are are equal the
testcase doesn't reliably predict the transformed result.

Fixing this can either occur by the patch I submitted in the above
thread, or by changing mathfn_built_in to give predictable results no
matter what the relative sizes of the FP types are.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Jan Hubicka]

>  > From: Jan Hubicka <jh@suse.cz>
>  > 
>  > > Yes, I know about this one.  See
>  > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
>  > > 
>  > > The discussion died off waiting for an explanation from Jan about
>  > > mathfn_built_in.
>  > 
>  > Sorry, I must've missed the thread completely :(
>  > And even now I can't find any question regarding mathfn_built_in in
>  > the thread.  It is supposed to return for given function and type
>  > equivalent of function operating on the type.
> 
> The question, as posed by rth in the thread here:
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html
> 
> is why in mathfn_built_in are we comparing the mode rather than
> type-main-variant?
> 
> Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)
> 
> When using mathfn_built_in on a system where the sizes of double and
> long double are the same, your algorithm will prefer the double
> version of the function and return plain pow even though we asked for
> the long double variant.
> 
> Was there a reason to write mathfn_built_in this way?  E.g. did you
> prefer the double type because you were trying to support pre-c99
> systems and did it this way before TARGET_C99_FUNCTIONS was
> introduced?

No, I guess I wrote it just because I was thinking in RTL way so modes
seemed more natural to compare.
> 
> If we have no reason to keep the mathfn_built_in algorithm this way,
> I'd like to change it to return predictable values regardless of the
> sizes of the FP types on the target.

That sounds fine to me.

Honza
> 
> 		Thanks,
> 		--Kaveh
> --
> Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Jan Hubicka]

>  > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>  > 
>  > The following tests are failing under hppa-unknown-linux-gnu:
>  > 
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O0  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O1  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O2  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -fomit-frame-pointer  (test for exce
>  > ss errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -g  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -Os  (test for excess errors)
>  > 
>  > On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
>  > the same size (as defined in defaults.h).  It has C99 functions.
>  > 
>  > I removed the long double tests from builtin-power-1.c and the tests
>  > then pass.  I think this points to a problem with the builtins when two
>  > types (double and long double) have the same size.
> 
> Yes, I know about this one.  See
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
> 
> The discussion died off waiting for an explanation from Jan about
> mathfn_built_in.

Sorry, I must've missed the thread completely :(
And even now I can't find any question regarding mathfn_built_in in the
thread.
It is supposed to return for given function and type equivalent of
function operating on the type.
> 
> This failure is harmless from a code correctness standpoint.  It's
> simply that when sizeof double and long double are are equal the
> testcase doesn't reliably predict the transformed result.
> 
> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.

You man converting the sinl into sin even when the types are equivalent?
I have nothing against this except that it may be somewhat irratitng to
user to see his code changed for no good reason.  But we do that all the
time :)

Honza
> 
> 		--Kaveh
> --
> Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[John David Anglin]

The following tests are failing under hppa-unknown-linux-gnu:

FAIL: gcc.dg/torture/builtin-power-1.c  -O0  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O2  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -fomit-frame-pointer  (test for exce
ss errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -Os  (test for excess errors)

On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
the same size (as defined in defaults.h).  It has C99 functions.

I removed the long double tests from builtin-power-1.c and the tests
then pass.  I think this points to a problem with the builtins when two
types (double and long double) have the same size.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: Jan Hubicka <jh@suse.cz>
 > 
 > > Yes, I know about this one.  See
 > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
 > > 
 > > The discussion died off waiting for an explanation from Jan about
 > > mathfn_built_in.
 > 
 > Sorry, I must've missed the thread completely :(
 > And even now I can't find any question regarding mathfn_built_in in
 > the thread.  It is supposed to return for given function and type
 > equivalent of function operating on the type.

The question, as posed by rth in the thread here:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html

is why in mathfn_built_in are we comparing the mode rather than
type-main-variant?

Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)

When using mathfn_built_in on a system where the sizes of double and
long double are the same, your algorithm will prefer the double
version of the function and return plain pow even though we asked for
the long double variant.

Was there a reason to write mathfn_built_in this way?  E.g. did you
prefer the double type because you were trying to support pre-c99
systems and did it this way before TARGET_C99_FUNCTIONS was
introduced?

If we have no reason to keep the mathfn_built_in algorithm this way,
I'd like to change it to return predictable values regardless of the
sizes of the FP types on the target.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Jan Hubicka]

>  > From: Jan Hubicka <jh@suse.cz>
>  > 
>  > > Yes, I know about this one.  See
>  > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
>  > > 
>  > > The discussion died off waiting for an explanation from Jan about
>  > > mathfn_built_in.
>  > 
>  > Sorry, I must've missed the thread completely :(
>  > And even now I can't find any question regarding mathfn_built_in in
>  > the thread.  It is supposed to return for given function and type
>  > equivalent of function operating on the type.
> 
> The question, as posed by rth in the thread here:
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html
> 
> is why in mathfn_built_in are we comparing the mode rather than
> type-main-variant?
> 
> Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)
> 
> When using mathfn_built_in on a system where the sizes of double and
> long double are the same, your algorithm will prefer the double
> version of the function and return plain pow even though we asked for
> the long double variant.
> 
> Was there a reason to write mathfn_built_in this way?  E.g. did you
> prefer the double type because you were trying to support pre-c99
> systems and did it this way before TARGET_C99_FUNCTIONS was
> introduced?

No, I guess I wrote it just because I was thinking in RTL way so modes
seemed more natural to compare.
> 
> If we have no reason to keep the mathfn_built_in algorithm this way,
> I'd like to change it to return predictable values regardless of the
> sizes of the FP types on the target.

That sounds fine to me.

Honza
> 
> 		Thanks,
> 		--Kaveh
> --
> Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: Jan Hubicka <jh@suse.cz>
 > 
 > > Yes, I know about this one.  See
 > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
 > > 
 > > The discussion died off waiting for an explanation from Jan about
 > > mathfn_built_in.
 > 
 > Sorry, I must've missed the thread completely :(
 > And even now I can't find any question regarding mathfn_built_in in
 > the thread.  It is supposed to return for given function and type
 > equivalent of function operating on the type.

The question, as posed by rth in the thread here:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html

is why in mathfn_built_in are we comparing the mode rather than
type-main-variant?

Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)

When using mathfn_built_in on a system where the sizes of double and
long double are the same, your algorithm will prefer the double
version of the function and return plain pow even though we asked for
the long double variant.

Was there a reason to write mathfn_built_in this way?  E.g. did you
prefer the double type because you were trying to support pre-c99
systems and did it this way before TARGET_C99_FUNCTIONS was
introduced?

If we have no reason to keep the mathfn_built_in algorithm this way,
I'd like to change it to return predictable values regardless of the
sizes of the FP types on the target.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Jan Hubicka]

>  > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>  > 
>  > The following tests are failing under hppa-unknown-linux-gnu:
>  > 
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O0  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O1  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O2  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -fomit-frame-pointer  (test for exce
>  > ss errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -g  (test for excess errors)
>  > FAIL: gcc.dg/torture/builtin-power-1.c  -Os  (test for excess errors)
>  > 
>  > On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
>  > the same size (as defined in defaults.h).  It has C99 functions.
>  > 
>  > I removed the long double tests from builtin-power-1.c and the tests
>  > then pass.  I think this points to a problem with the builtins when two
>  > types (double and long double) have the same size.
> 
> Yes, I know about this one.  See
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
> 
> The discussion died off waiting for an explanation from Jan about
> mathfn_built_in.

Sorry, I must've missed the thread completely :(
And even now I can't find any question regarding mathfn_built_in in the
thread.
It is supposed to return for given function and type equivalent of
function operating on the type.
> 
> This failure is harmless from a code correctness standpoint.  It's
> simply that when sizeof double and long double are are equal the
> testcase doesn't reliably predict the transformed result.
> 
> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.

You man converting the sinl into sin even when the types are equivalent?
I have nothing against this except that it may be somewhat irratitng to
user to see his code changed for no good reason.  But we do that all the
time :)

Honza
> 
> 		--Kaveh
> --
> Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[John David Anglin]

> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.

This might be the best approach.  There are also about a half-dozen
`long double' related testsuite failures on hppa-linux in the libstdc++
suite.  These might also be caused by the above uncertainty.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Kaveh R. Ghazi]

 > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
 > 
 > The following tests are failing under hppa-unknown-linux-gnu:
 > 
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O0  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O1  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O2  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -fomit-frame-pointer  (test for exce
 > ss errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -g  (test for excess errors)
 > FAIL: gcc.dg/torture/builtin-power-1.c  -Os  (test for excess errors)
 > 
 > On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
 > the same size (as defined in defaults.h).  It has C99 functions.
 > 
 > I removed the long double tests from builtin-power-1.c and the tests
 > then pass.  I think this points to a problem with the builtins when two
 > types (double and long double) have the same size.

Yes, I know about this one.  See
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html

The discussion died off waiting for an explanation from Jan about
mathfn_built_in.

This failure is harmless from a code correctness standpoint.  It's
simply that when sizeof double and long double are are equal the
testcase doesn't reliably predict the transformed result.

Fixing this can either occur by the patch I submitted in the above
thread, or by changing mathfn_built_in to give predictable results no
matter what the relative sizes of the FP types are.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[John David Anglin]

The following tests are failing under hppa-unknown-linux-gnu:

FAIL: gcc.dg/torture/builtin-power-1.c  -O0  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O1  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O2  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -fomit-frame-pointer  (test for exce
ss errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c  -Os  (test for excess errors)

On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
the same size (as defined in defaults.h).  It has C99 functions.

I removed the long double tests from builtin-power-1.c and the tests
then pass.  I think this points to a problem with the builtins when two
types (double and long double) have the same size.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt

[Ulrich Weigand]

Kaveh Ghazi wrote:

>        * builtins.c (fold_builtin): Add new builtin optimizations for
>        sqrt and/or cbrt.

>+                 dconstroot.exp--;

This causes bootstrap failure due to:
../../gcc-head/gcc/builtins.c: In function `fold_builtin':
../../gcc-head/gcc/builtins.c:6707: error: structure has no member named `exp'

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de