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