This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] New regressions as of 2003-11-04


In message <20031106172901.GA11820@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >Hello,
 >
 >> >>Lots of changes yesterday produced new regressions in C, C++, Fortran
 >> >>and mudflap.  I think I know what the mudflap problem is, so I'll take
 >> >>care of that.  Could you folks take a look at the new regressions and
 >> >>see if they're related to your changes?
 >> >>	 FAIL: gcc.dg/tree-ssa/20030814-4.c scan-tree-dump-times set = -1 0
 >> >>	 FAIL: gcc.dg/tree-ssa/20030814-5.c scan-tree-dump-times set = -1 0
 >> >OK.  After looking at these some more.  These are failures that are a
 >> >combination of the COND_EXPR lowering and some sillyness in PRE.
 >
 >this patch adds a cfg-aware version of remove_useless_..., thus fixing
 >these failures.
 >
 >Zdenek
 >
 >	* basic-block.h (create_bb): Declaration changed.
 >	* tree-cfg.c (create_bb): Enable creating a block on specified place.
 >	(make_blocks, tree_split_edge, tree_make_forwarder_block): Use it.
 >	(tree_verify_flow_info): Check bbs are in the correct order.
 >	(cfg_remove_useless_stmts_bb, cfg_remove_useless_stmts): New.
 >	(remove_unreachable_blocks): Remove missleading comments.
 >	* tree-flow.h (cfg_remove_useless_stmts): Declare.
 >	* tree-ssa.c (rewrite_out_of_ssa): Use cfg_remove_useless_stmts instead
 >	of remove_useless_stmts_and_vars.
So it looks like we've got two independent patches here.  One changes how
we link together blocks to keep them in a particular order, the other
is the addition of remove_useless_stmts_bb.  Seems to me these really should
have been two independent patches.

 >+ /* Remove obviously useless statements in basic block BB.  */
 >+ 
 >+ static void
 >+ cfg_remove_useless_stmts_bb (basic_block bb)
 >+ {
 >+   block_stmt_iterator bsi;
 >+   tree stmt;
 >+   tree *gotos[2], *pstmt;
 >+   int n_gotos, n_rem_gotos;
 >+   tree cond, var = NULL_TREE, val = NULL_TREE;
 >+   struct var_ann_d *ann;
 >+ 
 >+   /* Check whether we come here from a condition, and if so, get the
 >+      condition.  */
 >+   if (bb->pred && !bb->pred->pred_next
 >+       && (bb->pred->flags & (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE)))
 >+     {
 >+       cond = COND_EXPR_COND (last_stmt (bb->pred->src));
 >+       if (bb->pred->flags & EDGE_FALSE_VALUE)
 >+ 	cond = invert_truthvalue (cond);
At the least you should comment that EDGE_TRUE_VALUE and EDGE_FALSE_VALUE
can only be set on edges originating with a COND_EXPR thus last_stmt
should always return a COND_EXPR.




 >+   n_rem_gotos = n_gotos;
 >+   while (n_gotos--)
 >+     {
 >+       pstmt = gotos[n_gotos];
 >+       stmt = *pstmt;
 >+ 
 >+       if (TREE_CODE (GOTO_DESTINATION (stmt)) != LABEL_DECL)
 >+ 	continue;
 >+ 
 >+       if (label_to_block (GOTO_DESTINATION (stmt)) != bb->next_bb)
 >+ 	continue;
Is label_to_block 100% accurate at this point? ie, when we create new
blocks/labels do we update the label map?

Otherwise this part looks pretty good.  I didn't look at the stuff to
enforce an order on basic blocks.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]