public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Difference between {expand,fold,simplify}_builtin_foo ???
@ 2004-09-20 18:29 Kaveh R. Ghazi
  2004-09-20 18:38 ` Eric Christopher
  2004-09-20 18:45 ` Jeffrey A Law
  0 siblings, 2 replies; 9+ messages in thread
From: Kaveh R. Ghazi @ 2004-09-20 18:29 UTC (permalink / raw)
  To: gcc

I've been out of GCC most of the summer, so I don't know if this was
discussed or not.  I was wondering what's the reason for and
difference between {expand,fold,simplify}_builtin_foo().

Looking at e.g. expand_builtin_sprintf and simplify_builtin_sprintf,
they seem to do exactly the same transformations.  Can we just have
expand_builtin_sprintf call simplify_builtin_sprintf and then expand
the result?  This would remove lots of code duplication and potential
locations of errors.

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

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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-20 18:29 Difference between {expand,fold,simplify}_builtin_foo ??? Kaveh R. Ghazi
@ 2004-09-20 18:38 ` Eric Christopher
  2004-09-20 19:51   ` Kaveh R. Ghazi
  2004-09-20 18:45 ` Jeffrey A Law
  1 sibling, 1 reply; 9+ messages in thread
From: Eric Christopher @ 2004-09-20 18:38 UTC (permalink / raw)
  To: Kaveh R. Ghazi; +Cc: gcc

On Mon, 2004-09-20 at 10:41, Kaveh R. Ghazi wrote:
> I've been out of GCC most of the summer, so I don't know if this was
> discussed or not.  I was wondering what's the reason for and
> difference between {expand,fold,simplify}_builtin_foo().
> 
> Looking at e.g. expand_builtin_sprintf and simplify_builtin_sprintf,
> they seem to do exactly the same transformations.  Can we just have
> expand_builtin_sprintf call simplify_builtin_sprintf and then expand
> the result?  This would remove lots of code duplication and potential
> locations of errors.

I've got a patch in the works that removes most of the simplify_*
routines. Some of them I've uh... folded... into fold_* and others I'm
doing what you said here. :)

I'll probably get back to it later today :)

-eric

-- 
Eric Christopher <echristo@redhat.com>

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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-20 18:29 Difference between {expand,fold,simplify}_builtin_foo ??? Kaveh R. Ghazi
  2004-09-20 18:38 ` Eric Christopher
@ 2004-09-20 18:45 ` Jeffrey A Law
  2004-09-20 20:04   ` Kaveh R. Ghazi
  1 sibling, 1 reply; 9+ messages in thread
From: Jeffrey A Law @ 2004-09-20 18:45 UTC (permalink / raw)
  To: Kaveh R. Ghazi; +Cc: gcc

On Mon, 2004-09-20 at 11:41, Kaveh R. Ghazi wrote:
> I've been out of GCC most of the summer, so I don't know if this was
> discussed or not.  I was wondering what's the reason for and
> difference between {expand,fold,simplify}_builtin_foo().
> 
> Looking at e.g. expand_builtin_sprintf and simplify_builtin_sprintf,
> they seem to do exactly the same transformations.  Can we just have
> expand_builtin_sprintf call simplify_builtin_sprintf and then expand
> the result?  This would remove lots of code duplication and potential
> locations of errors.
I thought that had already been done where possible.

The key difference between them is the simplify_ variant is not
allowed to generate RTL nor create non-gimple code.

jeff


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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-20 18:38 ` Eric Christopher
@ 2004-09-20 19:51   ` Kaveh R. Ghazi
  2004-09-22  6:04     ` Eric Christopher
  0 siblings, 1 reply; 9+ messages in thread
From: Kaveh R. Ghazi @ 2004-09-20 19:51 UTC (permalink / raw)
  To: echristo; +Cc: gcc

 > I've got a patch in the works that removes most of the simplify_*
 > routines. Some of them I've uh... folded... into fold_* and others
 > I'm doing what you said here. :)
 > I'll probably get back to it later today :)
 > -eric

Great!  I'd be happy to help, but to avoid stomping on the same code
I'll avoid doing anything until I see what your patch catches.

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

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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-20 18:45 ` Jeffrey A Law
@ 2004-09-20 20:04   ` Kaveh R. Ghazi
  2004-09-21  7:53     ` Jeffrey A Law
  0 siblings, 1 reply; 9+ messages in thread
From: Kaveh R. Ghazi @ 2004-09-20 20:04 UTC (permalink / raw)
  To: law; +Cc: gcc


 > The key difference between them is the simplify_ variant is not
 > allowed to generate RTL nor create non-gimple code.
 > jeff

Ok thanks, that explains expand_builtin_* vs. simplify_builtin_*.

However what about fold_builtin_*?  Both fold_builin_* and
simplify_builtin_* return trees.  Are the fold_ variants allowed to
produce non-gimple?  Or are fold_builtin_* and simplify_builtin_*
really the same and we should canonicalize the naming convention?

If so, which is preferred?

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

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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-20 20:04   ` Kaveh R. Ghazi
@ 2004-09-21  7:53     ` Jeffrey A Law
  2004-09-22  9:38       ` Roger Sayle
  0 siblings, 1 reply; 9+ messages in thread
From: Jeffrey A Law @ 2004-09-21  7:53 UTC (permalink / raw)
  To: Kaveh R. Ghazi; +Cc: gcc

On Mon, 2004-09-20 at 12:45, Kaveh R. Ghazi wrote:
>  > The key difference between them is the simplify_ variant is not
>  > allowed to generate RTL nor create non-gimple code.
>  > jeff
> 
> Ok thanks, that explains expand_builtin_* vs. simplify_builtin_*.
> 
> However what about fold_builtin_*?  Both fold_builin_* and
> simplify_builtin_* return trees.  Are the fold_ variants allowed to
> produce non-gimple?  Or are fold_builtin_* and simplify_builtin_*
> really the same and we should canonicalize the naming convention?
I didn't realize we had a 3rd routine.  Ugh.  I don't know which is
preferred.  Sigh.

jeff


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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-20 19:51   ` Kaveh R. Ghazi
@ 2004-09-22  6:04     ` Eric Christopher
  2004-09-22 17:34       ` Richard Henderson
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Christopher @ 2004-09-22  6:04 UTC (permalink / raw)
  To: Kaveh R. Ghazi; +Cc: gcc, law

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

On Mon, 2004-09-20 at 11:38, Kaveh R. Ghazi wrote:
>  > I've got a patch in the works that removes most of the simplify_*
>  > routines. Some of them I've uh... folded... into fold_* and others
>  > I'm doing what you said here. :)
>  > I'll probably get back to it later today :)
>  > -eric
> 
> Great!  I'd be happy to help, but to avoid stomping on the same code
> I'll avoid doing anything until I see what your patch catches.

The attached patch, sans ChangeLog, bootstraps ok on x86-linux.

Since it's not a straight rename I'll run it through a test. I needed to
change and eliminate simplify/fold_builtin_va_start since it's only use
was as a warning mechanism and it can do that just fine in the expand
function - where we redid half the warnings anyhow. Unfortunately it
doesn't seem to change the special casing in gimplify.c where we have
BUILT_IN_VA_START called out, at least I don't think so :)

I'll run it through some testing tonight and submit it with a ChangeLog
tomorrow.

-eric

-- 
Eric Christopher <echristo@redhat.com>

[-- Attachment #2: simplify.diff --]
[-- Type: text/x-patch, Size: 15088 bytes --]

Index: builtins.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/builtins.c,v
retrieving revision 1.386
diff -u -p -w -r1.386 builtins.c
--- builtins.c	20 Sep 2004 14:47:17 -0000	1.386
+++ builtins.c	22 Sep 2004 01:09:40 -0000
@@ -164,7 +164,7 @@ static tree fold_builtin_bitop (tree);
 static tree fold_builtin_memcpy (tree);
 static tree fold_builtin_mempcpy (tree);
 static tree fold_builtin_memmove (tree);
-static tree fold_builtin_strchr (tree, bool);
+static tree fold_builtin_strchr (tree);
 static tree fold_builtin_memcmp (tree);
 static tree fold_builtin_strcmp (tree);
 static tree fold_builtin_strncmp (tree);
@@ -178,17 +178,15 @@ static tree fold_builtin_abs (tree, tree
 static tree fold_builtin_unordered_cmp (tree, enum tree_code, enum tree_code);
 static tree fold_builtin_1 (tree, bool);
 
-static tree simplify_builtin_strpbrk (tree);
-static tree simplify_builtin_strstr (tree);
-static tree simplify_builtin_strchr (tree);
-static tree simplify_builtin_strrchr (tree);
-static tree simplify_builtin_strcat (tree);
-static tree simplify_builtin_strncat (tree);
-static tree simplify_builtin_strspn (tree);
-static tree simplify_builtin_strcspn (tree);
-static void simplify_builtin_next_arg (tree);
-static void simplify_builtin_va_start (tree);
-static tree simplify_builtin_sprintf (tree, int);
+static tree fold_builtin_strpbrk (tree);
+static tree fold_builtin_strstr (tree);
+static tree fold_builtin_strrchr (tree);
+static tree fold_builtin_strcat (tree);
+static tree fold_builtin_strncat (tree);
+static tree fold_builtin_strspn (tree);
+static tree fold_builtin_strcspn (tree);
+static void fold_builtin_next_arg (tree);
+static tree fold_builtin_sprintf (tree, int);
 
 
 /* Return the alignment in bits of EXP, a pointer valued expression.
@@ -4286,6 +4284,8 @@ expand_builtin_va_start (tree arglist)
   if (TREE_CHAIN (chain))
     error ("too many arguments to function %<va_start%>");
 
+  fold_builtin_next_arg (chain);
+
   nextarg = expand_builtin_next_arg (chain);
   valist = stabilize_va_list (TREE_VALUE (arglist), 1);
 
@@ -5728,7 +5728,7 @@ expand_builtin (tree exp, rtx target, rt
 
       /* Return the address of the first anonymous stack arg.  */
     case BUILT_IN_NEXT_ARG:
-      simplify_builtin_next_arg (arglist);
+      fold_builtin_next_arg (arglist);
       return expand_builtin_next_arg (arglist);
 
     case BUILT_IN_CLASSIFY_TYPE:
@@ -7576,61 +7576,6 @@ fold_builtin_strncpy (tree exp, tree sle
 		       build_function_call_expr (fn, arglist));
 }
 
-/* Fold function call to builtin strchr and strrchr.
-   Return NULL_TREE if no simplification can be made.  */
-
-static tree
-fold_builtin_strchr (tree exp, bool actually_strrchr)
-{
-  tree arglist = TREE_OPERAND (exp, 1);
-  if (!validate_arglist (arglist, POINTER_TYPE, INTEGER_TYPE, VOID_TYPE))
-    return 0;
-  else
-    {
-      tree s1 = TREE_VALUE (arglist), s2 = TREE_VALUE (TREE_CHAIN (arglist));
-      const char *p1;
-
-      if (TREE_CODE (s2) != INTEGER_CST)
-	return 0;
-
-      p1 = c_getstr (s1);
-      if (p1 != NULL)
-	{
-	  char c;
-	  const char *r;
-
-	  if (target_char_cast (s2, &c))
-	    return 0;
-
-	  r = actually_strrchr ? strrchr (p1, c) : strchr (p1, c);
-
-	  if (r == NULL)
-	    return build_int_cst (TREE_TYPE (s1), 0);
-
-	  /* Return an offset into the constant string argument.  */
-	  return fold (build2 (PLUS_EXPR, TREE_TYPE (s1),
-			       s1, build_int_cst (TREE_TYPE (s1), r - p1)));
-	}
-
-      if (actually_strrchr)
-	{
-	  tree fn;
-
-	  if (!integer_zerop (s2))
-	    return 0;
-
-	  fn = implicit_built_in_decls[BUILT_IN_STRCHR];
-	  if (!fn)
-	    return 0;
-
-	  /* Transform strrchr(s1, '\0') to strchr(s1, '\0').  */
-	  return build_function_call_expr (fn, arglist);
-	}
-
-      return 0;
-    }
-}
-
 /* Fold function call to builtin memcmp.  Return
    NULL_TREE if no simplification can be made.  */
 
@@ -8210,8 +8155,70 @@ fold_builtin_1 (tree exp, bool ignore)
 
   switch (DECL_FUNCTION_CODE (fndecl))
     {
+    case BUILT_IN_FPUTS:
+      return fold_builtin_fputs (arglist, ignore, false, NULL_TREE);
+
+    case BUILT_IN_FPUTS_UNLOCKED:
+      return fold_builtin_fputs (arglist, ignore, true, NULL_TREE);
+
+    case BUILT_IN_STRSTR:
+      return fold_builtin_strstr (arglist);
+
+    case BUILT_IN_STRCAT:
+      return fold_builtin_strcat (arglist);
+
+    case BUILT_IN_STRNCAT:
+      return fold_builtin_strncat (arglist);
+
+    case BUILT_IN_STRSPN:
+      return fold_builtin_strspn (arglist);
+
+    case BUILT_IN_STRCSPN:
+      return fold_builtin_strcspn (arglist);
+
+    case BUILT_IN_STRCHR:
+    case BUILT_IN_INDEX:
+      return fold_builtin_strchr (arglist);
+
+    case BUILT_IN_STRRCHR:
+    case BUILT_IN_RINDEX:
+      return fold_builtin_strrchr (arglist);
+
+    case BUILT_IN_STRCPY:
+      return fold_builtin_strcpy (exp, NULL_TREE);
+
+    case BUILT_IN_STRNCPY:
+      return fold_builtin_strncpy (exp, NULL_TREE);
+
+    case BUILT_IN_STRCMP:
+      return fold_builtin_strcmp (arglist);
+
+    case BUILT_IN_STRNCMP:
+      return fold_builtin_strncmp (arglist);
+
+    case BUILT_IN_STRPBRK:
+      return fold_builtin_strpbrk (arglist);
+
+    case BUILT_IN_BCMP:
+    case BUILT_IN_MEMCMP:
+      return fold_builtin_memcmp (arglist);
+
+    case BUILT_IN_SPRINTF:
+      return fold_builtin_sprintf (arglist, ignore);
+
     case BUILT_IN_CONSTANT_P:
-      return fold_builtin_constant_p (arglist);
+      {
+	tree val;
+
+	val = fold_builtin_constant_p (arglist);
+	/* Gimplification will pull the CALL_EXPR for the builtin out of
+	   an if condition.  When not optimizing, we'll not CSE it back.
+	   To avoid link error types of regressions, return false now.  */
+	if (!val && !optimize)
+	  val = integer_zero_node;
+
+	return val;
+      }
 
     case BUILT_IN_EXPECT:
       return fold_builtin_expect (arglist);
@@ -8419,29 +8426,6 @@ fold_builtin_1 (tree exp, bool ignore)
     case BUILT_IN_MEMMOVE:
       return fold_builtin_memmove (exp);
 
-    case BUILT_IN_STRCPY:
-      return fold_builtin_strcpy (exp, NULL_TREE);
-
-    case BUILT_IN_STRNCPY:
-      return fold_builtin_strncpy (exp, NULL_TREE);
-
-    case BUILT_IN_INDEX:
-    case BUILT_IN_STRCHR:
-      return fold_builtin_strchr (exp, false);
-
-    case BUILT_IN_RINDEX:
-    case BUILT_IN_STRRCHR:
-      return fold_builtin_strchr (exp, true);
-
-    case BUILT_IN_MEMCMP:
-      return fold_builtin_memcmp (arglist);
-
-    case BUILT_IN_STRCMP:
-      return fold_builtin_strcmp (arglist);
-
-    case BUILT_IN_STRNCMP:
-      return fold_builtin_strncmp (arglist);
-
     case BUILT_IN_SIGNBIT:
     case BUILT_IN_SIGNBITF:
     case BUILT_IN_SIGNBITL:
@@ -8489,11 +8473,9 @@ fold_builtin_1 (tree exp, bool ignore)
     case BUILT_IN_ISUNORDERED:
       return fold_builtin_unordered_cmp (exp, UNORDERED_EXPR, NOP_EXPR);
 
-    case BUILT_IN_FPUTS:
-      return fold_builtin_fputs (arglist, ignore, false, NULL_TREE);
-
-    case BUILT_IN_FPUTS_UNLOCKED:
-      return fold_builtin_fputs (arglist, ignore, true, NULL_TREE);
+      /* We do the folding for va_start in the expander.  */
+    case BUILT_IN_VA_START:
+      break;
 
     default:
       break;
@@ -8517,6 +8499,7 @@ fold_builtin (tree exp, bool ignore)
 	exp = build1 (NOP_EXPR, TREE_TYPE (exp), exp);
       TREE_NO_WARNING (exp) = 1;
     }
+
   return exp;
 }
 
@@ -8620,101 +8603,6 @@ readonly_data_expr (tree exp)
     return false;
 }
 
-/* Front-end to the simplify_builtin_XXX routines.
-
-   EXP is a call to a builtin function.  If possible try to simplify
-   that into a constant, expression or call to a more efficient
-   builtin function.
-
-   If IGNORE is nonzero, then the result of this builtin function
-   call is ignored.
-
-   If simplification is possible, return the simplified tree, otherwise
-   return NULL_TREE.  */
-
-tree
-simplify_builtin (tree exp, int ignore)
-{
-  tree fndecl = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
-  tree arglist = TREE_OPERAND (exp, 1);
-  enum built_in_function fcode = DECL_FUNCTION_CODE (fndecl);
-  tree val;
-
-  switch (fcode)
-    {
-    case BUILT_IN_FPUTS:
-      val = fold_builtin_fputs (arglist, ignore, false, NULL_TREE);
-      break;
-    case BUILT_IN_FPUTS_UNLOCKED:
-      val = fold_builtin_fputs (arglist, ignore, true, NULL_TREE);
-      break;
-    case BUILT_IN_STRSTR:
-      val = simplify_builtin_strstr (arglist);
-      break;
-    case BUILT_IN_STRCAT:
-      val = simplify_builtin_strcat (arglist);
-      break;
-    case BUILT_IN_STRNCAT:
-      val = simplify_builtin_strncat (arglist);
-      break;
-    case BUILT_IN_STRSPN:
-      val = simplify_builtin_strspn (arglist);
-      break;
-    case BUILT_IN_STRCSPN:
-      val = simplify_builtin_strcspn (arglist);
-      break;
-    case BUILT_IN_STRCHR:
-    case BUILT_IN_INDEX:
-      val = simplify_builtin_strchr (arglist);
-      break;
-    case BUILT_IN_STRRCHR:
-    case BUILT_IN_RINDEX:
-      val = simplify_builtin_strrchr (arglist);
-      break;
-    case BUILT_IN_STRCPY:
-      val = fold_builtin_strcpy (exp, NULL_TREE);
-      break;
-    case BUILT_IN_STRNCPY:
-      val = fold_builtin_strncpy (exp, NULL_TREE);
-      break;
-    case BUILT_IN_STRCMP:
-      val = fold_builtin_strcmp (arglist);
-      break;
-    case BUILT_IN_STRNCMP:
-      val = fold_builtin_strncmp (arglist);
-      break;
-    case BUILT_IN_STRPBRK:
-      val = simplify_builtin_strpbrk (arglist);
-      break;
-    case BUILT_IN_BCMP:
-    case BUILT_IN_MEMCMP:
-      val = fold_builtin_memcmp (arglist);
-      break;
-    case BUILT_IN_VA_START:
-      simplify_builtin_va_start (arglist);
-      val = NULL_TREE;
-      break;
-    case BUILT_IN_SPRINTF:
-      val = simplify_builtin_sprintf (arglist, ignore);
-      break;
-    case BUILT_IN_CONSTANT_P:
-      val = fold_builtin_constant_p (arglist);
-      /* Gimplification will pull the CALL_EXPR for the builtin out of
-	 an if condition.  When not optimizing, we'll not CSE it back.
-	 To avoid link error types of regressions, return false now.  */
-      if (!val && !optimize)
-	val = integer_zero_node;
-      break;
-    default:
-      val = NULL_TREE;
-      break;
-    }
-
-  if (val)
-    val = fold_convert (TREE_TYPE (exp), val);
-  return val;
-}
-
 /* Simplify a call to the strstr builtin.
 
    Return 0 if no simplification was possible, otherwise return the
@@ -8733,7 +8621,7 @@ simplify_builtin (tree exp, int ignore)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strstr (tree arglist)
+fold_builtin_strstr (tree arglist)
 {
   if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
     return 0;
@@ -8797,7 +8685,7 @@ simplify_builtin_strstr (tree arglist)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strchr (tree arglist)
+fold_builtin_strchr (tree arglist)
 {
   if (!validate_arglist (arglist, POINTER_TYPE, INTEGER_TYPE, VOID_TYPE))
     return 0;
@@ -8852,7 +8740,7 @@ simplify_builtin_strchr (tree arglist)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strrchr (tree arglist)
+fold_builtin_strrchr (tree arglist)
 {
   if (!validate_arglist (arglist, POINTER_TYPE, INTEGER_TYPE, VOID_TYPE))
     return 0;
@@ -8914,7 +8802,7 @@ simplify_builtin_strrchr (tree arglist)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strpbrk (tree arglist)
+fold_builtin_strpbrk (tree arglist)
 {
   if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
     return 0;
@@ -8980,7 +8868,7 @@ simplify_builtin_strpbrk (tree arglist)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strcat (tree arglist)
+fold_builtin_strcat (tree arglist)
 {
   if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
     return 0;
@@ -9016,7 +8904,7 @@ simplify_builtin_strcat (tree arglist)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strncat (tree arglist)
+fold_builtin_strncat (tree arglist)
 {
   if (!validate_arglist (arglist,
 			 POINTER_TYPE, POINTER_TYPE, INTEGER_TYPE, VOID_TYPE))
@@ -9071,7 +8959,7 @@ simplify_builtin_strncat (tree arglist)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strspn (tree arglist)
+fold_builtin_strspn (tree arglist)
 {
   if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
     return 0;
@@ -9115,7 +9003,7 @@ simplify_builtin_strspn (tree arglist)
    form of the builtin function call.  */
 
 static tree
-simplify_builtin_strcspn (tree arglist)
+fold_builtin_strcspn (tree arglist)
 {
   if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
     return 0;
@@ -9242,18 +9130,7 @@ fold_builtin_fputs (tree arglist, bool i
 }
 
 static void
-simplify_builtin_va_start (tree arglist)
-{
-  tree chain = TREE_CHAIN (arglist);
-
-  if (TREE_CHAIN (chain))
-    error ("too many arguments to function %<va_start%>");
-
-  simplify_builtin_next_arg (chain);
-}
-
-static void
-simplify_builtin_next_arg (tree arglist)
+fold_builtin_next_arg (tree arglist)
 {
   tree fntype = TREE_TYPE (current_function_decl);
 
@@ -9293,7 +9170,7 @@ simplify_builtin_next_arg (tree arglist)
    the caller does not use the returned value of the function.  */
 
 static tree
-simplify_builtin_sprintf (tree arglist, int ignored)
+fold_builtin_sprintf (tree arglist, int ignored)
 {
   tree call, retval, dest, fmt;
   const char *fmt_str = NULL;
Index: gimplify.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.79
diff -u -p -w -r2.79 gimplify.c
--- gimplify.c	17 Sep 2004 21:54:35 -0000	2.79
+++ gimplify.c	22 Sep 2004 01:09:40 -0000
@@ -1769,7 +1769,7 @@ gimplify_call_expr (tree *expr_p, tree *
   decl = get_callee_fndecl (*expr_p);
   if (decl && DECL_BUILT_IN (decl))
     {
-      tree new = simplify_builtin (*expr_p, !want_value);
+      tree new = fold_builtin (*expr_p, !want_value);
 
       if (new && new != *expr_p)
 	{
@@ -1810,7 +1810,7 @@ gimplify_call_expr (tree *expr_p, tree *
   /* Try this again in case gimplification exposed something.  */
   if (ret != GS_ERROR && decl && DECL_BUILT_IN (decl))
     {
-      tree new = simplify_builtin (*expr_p, !want_value);
+      tree new = fold_builtin (*expr_p, !want_value);
 
       if (new && new != *expr_p)
 	{
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.626
diff -u -p -w -r1.626 tree.h
--- tree.h	21 Sep 2004 03:18:59 -0000	1.626
+++ tree.h	22 Sep 2004 01:09:41 -0000
@@ -3556,7 +3556,6 @@ extern enum built_in_function builtin_ma
 extern tree build_function_call_expr (tree, tree);
 extern tree mathfn_built_in (tree, enum built_in_function fn);
 extern tree strip_float_extensions (tree);
-extern tree simplify_builtin (tree, int);
 extern tree c_strlen (tree, int);
 extern tree std_gimplify_va_arg_expr (tree, tree, tree *, tree *);
 extern tree build_va_arg_indirect_ref (tree);

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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-21  7:53     ` Jeffrey A Law
@ 2004-09-22  9:38       ` Roger Sayle
  0 siblings, 0 replies; 9+ messages in thread
From: Roger Sayle @ 2004-09-22  9:38 UTC (permalink / raw)
  To: Jeffrey A Law, Kaveh Ghazi, Eric Christopher; +Cc: gcc


On Mon, 20 Sep 2004, Jeffrey A Law wrote:
> > However what about fold_builtin_*?  Both fold_builin_* and
> > simplify_builtin_* return trees.  Are the fold_ variants allowed to
> > produce non-gimple?  Or are fold_builtin_* and simplify_builtin_*
> > really the same and we should canonicalize the naming convention?
> I didn't realize we had a 3rd routine.  Ugh.  I don't know which is
> preferred.  Sigh.

Hi Jeff and Kaveh,

My understanding/intention is that fold_builtin_foo is the preferred
tree folding interface, and it is allowed to generate non-gimple trees.
All the uses of simplify_builtin and fold_builtin in the middle-end and
tree-ssa have been converted to check whether their return values are
in gimple form and either ignore the result, or thanks to Jakub's recent
patch re-gimplify it.  The APIs to both fold_builtin and simplify_builtin
have been synchronized, such that as functionality is consolidated between
the two fold_builtin will eventually be a replacement for simplify_builtin
and all the simplify_builtin_foo forms can go away.

Generally, there should not be a need to call fold_builtin_foo (or
simplify_builtin_foo) from the RTL expanders such as expand_builtin_foo.
The RTL expansion should be able to rely on the tree being fully folded
prior to expansion, however, there may be some duplication of these
optimizations when the expand_builtin_* functions checks whether RTL
expansion has introduced an optimization opportunity, i.e. checking
whether expand_expr has return const0_rtx, where the fold form may have
checked for integer_zerop.


This duplication dates back to the branch for tree-ssa where in the
tree-ssa development tree the simplify_* forms of these functions were
added to enable optimizations during tree-ssa's DOM and CCP passes,
whilst on mainline the usual usual improvements/clean-ups in constant
folding resulted in fold_builtin with near identical functionality.
Originally on mainline fold was "destructive" and therefore unsuitable
for tree-ssa, and tree-ssa at that time could only handle gimple trees.
Once  the branch/mainline were merged this became needless duplication
and the effort of integrating the two schemes continued:

See http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00312.html


Anyway, I hope this explains where things currently stand, or my
perspective of it.  Eric Christopher's patch looks exactly right :>


Roger
--

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

* Re: Difference between {expand,fold,simplify}_builtin_foo ???
  2004-09-22  6:04     ` Eric Christopher
@ 2004-09-22 17:34       ` Richard Henderson
  0 siblings, 0 replies; 9+ messages in thread
From: Richard Henderson @ 2004-09-22 17:34 UTC (permalink / raw)
  To: Eric Christopher; +Cc: Kaveh R. Ghazi, gcc, law

On Tue, Sep 21, 2004 at 06:15:01PM -0700, Eric Christopher wrote:
> I needed to change and eliminate simplify/fold_builtin_va_start since
> it's only use was as a warning mechanism and it can do that just fine
> in the expand function...

No, not really.  The expand function won't be called if we have 
a gimplifier.  Please move the warning into the front end.



r~

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

end of thread, other threads:[~2004-09-22 16:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-20 18:29 Difference between {expand,fold,simplify}_builtin_foo ??? Kaveh R. Ghazi
2004-09-20 18:38 ` Eric Christopher
2004-09-20 19:51   ` Kaveh R. Ghazi
2004-09-22  6:04     ` Eric Christopher
2004-09-22 17:34       ` Richard Henderson
2004-09-20 18:45 ` Jeffrey A Law
2004-09-20 20:04   ` Kaveh R. Ghazi
2004-09-21  7:53     ` Jeffrey A Law
2004-09-22  9:38       ` Roger Sayle

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