* [PATCH] Fix PR middle-end/17967, remove_useless_stmts is slow
@ 2004-10-14 18:37 Andrew Pinski
2004-10-14 21:01 ` Richard Henderson
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Pinski @ 2004-10-14 18:37 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
RTH helped me find that the problem in r_u_s is that we are calling
fold_stmt which is slow as there are huge number of statements in this
testcase.
The following patch added the calls to fold_stmt:
2004-01-10 Jan Hubicka <jh@suse.cz>
* tree-cfg.c (remove_usless_stmts_cond): Fold statement.
(remove_useless_stmts_1): Fold trees we know how to fold.
If we revert this patch we actually speed up GCC for the following
testcase:
#define ELSEIF1 else if (!a) f();
#define ELSEIF2 ELSEIF1 else if (a) ;
#define ELSEIF4 ELSEIF2 ELSEIF2
#define ELSEIF8 ELSEIF4 ELSEIF4
#define ELSEIF16 ELSEIF8 ELSEIF8
#define ELSEIF32 ELSEIF16 ELSEIF16
#define ELSEIF64 ELSEIF32 ELSEIF32
#define ELSEIF128 ELSEIF64 ELSEIF64
#define ELSEIF256 ELSEIF128 ELSEIF128
#define ELSEIF512 ELSEIF256 ELSEIF256
#define ELSEIF1024 ELSEIF512 ELSEIF512
#define ELSEIF2048 ELSEIF1024 ELSEIF1024
#define ELSEIF4096 ELSEIF2048 ELSEIF2048
void
foo (int a)
{
int b;
if (a);
ELSEIF4096
}
OK? Boostrapped and tested on ppc-darwin.
Thanks,
Andrew Pinski
ChangeLog:
Revert:
* tree-cfg.c (remove_usless_stmts_cond): Fold statement.
(remove_useless_stmts_1): Fold trees we know how to fold.
Patch:
[-- Attachment #2: temp.diff.txt --]
[-- Type: text/plain, Size: 1362 bytes --]
Index: tree-cfg.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.74
diff -u -p -r2.74 tree-cfg.c
--- tree-cfg.c 10 Oct 2004 13:16:35 -0000 2.74
+++ tree-cfg.c 14 Oct 2004 17:59:54 -0000
@@ -1204,7 +1204,6 @@ remove_useless_stmts_cond (tree *stmt_p,
else_has_label = data->has_label;
data->has_label = save_has_label | then_has_label | else_has_label;
- fold_stmt (stmt_p);
then_clause = COND_EXPR_THEN (*stmt_p);
else_clause = COND_EXPR_ELSE (*stmt_p);
cond = COND_EXPR_COND (*stmt_p);
@@ -1552,13 +1551,11 @@ remove_useless_stmts_1 (tree *tp, struct
break;
case RETURN_EXPR:
- fold_stmt (tp);
data->last_goto = NULL;
data->may_branch = true;
break;
case CALL_EXPR:
- fold_stmt (tp);
data->last_goto = NULL;
notice_special_calls (t);
update_call_expr_flags (t);
@@ -1568,7 +1565,6 @@ remove_useless_stmts_1 (tree *tp, struct
case MODIFY_EXPR:
data->last_goto = NULL;
- fold_stmt (tp);
op = get_call_expr_in (t);
if (op)
{
@@ -1604,10 +1600,6 @@ remove_useless_stmts_1 (tree *tp, struct
}
}
break;
- case SWITCH_EXPR:
- fold_stmt (tp);
- data->last_goto = NULL;
- break;
default:
data->last_goto = NULL;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Fix PR middle-end/17967, remove_useless_stmts is slow
2004-10-14 18:37 [PATCH] Fix PR middle-end/17967, remove_useless_stmts is slow Andrew Pinski
@ 2004-10-14 21:01 ` Richard Henderson
2004-10-15 4:19 ` Andrew Pinski
0 siblings, 1 reply; 3+ messages in thread
From: Richard Henderson @ 2004-10-14 21:01 UTC (permalink / raw)
To: Andrew Pinski; +Cc: GCC Patches, Jan Hubicka
On Thu, Oct 14, 2004 at 02:36:41PM -0400, Andrew Pinski wrote:
> * tree-cfg.c (remove_usless_stmts_cond): Fold statement.
> (remove_useless_stmts_1): Fold trees we know how to fold.
Ok.
r~
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Fix PR middle-end/17967, remove_useless_stmts is slow
2004-10-14 21:01 ` Richard Henderson
@ 2004-10-15 4:19 ` Andrew Pinski
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Pinski @ 2004-10-15 4:19 UTC (permalink / raw)
To: Richard Henderson; +Cc: Jan Hubicka, GCC Patches
On Oct 14, 2004, at 4:52 PM, Richard Henderson wrote:
> On Thu, Oct 14, 2004 at 02:36:41PM -0400, Andrew Pinski wrote:
>> * tree-cfg.c (remove_usless_stmts_cond): Fold statement.
>> (remove_useless_stmts_1): Fold trees we know how to fold.
>
> Ok.
I reverted it because I did not test fully and found that it
causes some regressions. Most of them are caused by fold (and
the C front-end which has other issues than talked about here)
not being able to fold &a[0]+1 into &a[1] unlike what fold_stmt
can do.
Why did someone put this part of the foldder into the fold_stmt
instead of fold I don't know (Diego was it you?).
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-10-15 4:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-14 18:37 [PATCH] Fix PR middle-end/17967, remove_useless_stmts is slow Andrew Pinski
2004-10-14 21:01 ` Richard Henderson
2004-10-15 4:19 ` Andrew Pinski
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).