This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] New regressions as of 2003-11-04
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, Jan Hubicka <jh at suse dot cz>, Daniel Berlin <dberlin at dberlin dot org>, Diego Novillo <dnovillo at redhat dot com>
- Date: Mon, 10 Nov 2003 15:10:29 -0700
- Subject: Re: [tree-ssa] New regressions as of 2003-11-04
- Reply-to: law at redhat dot com
In message <20031106172901.GA11820@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
>> >>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
> * 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, *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)
>+ if (label_to_block (GOTO_DESTINATION (stmt)) != bb->next_bb)
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.