This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Avoid rescanning cfg in tree cfg cleanup
- From: Diego Novillo <dnovillo at acm dot org>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 26 Apr 2007 14:50:46 -0400
- Subject: Re: [patch] Avoid rescanning cfg in tree cfg cleanup
- References: <20070329200800.GA13701@atrey.karlin.mff.cuni.cz>
Zdenek Dvorak wrote on 03/29/07 16:08:
> According to my measurements, this change speeds up tree cfg cleanup
> by about 20%. The effect on the compilation time is less significant,
> sice tree cfg cleanup usually takes something like 1% of the compilation
> time.
Nice.
> * tree-cfgcleanup.c (cfgcleanup_altered_bbs): New global variable.
> (remove_fallthru_edge): Use remove_edge_and_dominated_blocks.
> (cleanup_control_expr_graph): Do not invalidate dominance info.
> Record altered blocks.
> (cleanup_control_flow, cleanup_forwarder_blocks): Removed.
> (cleanup_control_flow_bb, split_bbs_on_noreturn_calls,
> cleanup_tree_cfg_bb): New functions.
> (remove_forwarder_block): Do not maintain the worklist of blocks.
> Record altered blocks.
> (cleanup_tree_cfg_1): Iterate over cfgcleanup_altered_bbs,
> not over whole cfg.
> (cleanup_tree_cfg): Do not iterate cleanup_tree_cfg_1. Only call
> delete_unreachable_blocks if dominators are not available.
> * tree-inline.c (optimize_inline_calls): Free dominance information
> earlier.
> * tree-flow.h (remove_edge_and_dominated_blocks,
> cfgcleanup_altered_bbs): Altered.
> * tree-cfg.c (replace_uses_by, tree_merge_blocks): Record altered
> blocks.
> (get_all_dominated_blocks, remove_edge_and_dominated_blocks): New
> functions.
> (tree_purge_dead_eh_edges): Use remove_edge_and_dominated_blocks,
> do not invalidate dominators.
OK.
> + /* The set of blocks in that at least one of the following changes happened:
> + -- the statement at the end of the block was changed
> + -- the block was newly created
> + -- the set of the predecessors of the block changed
> + -- the set of the successors of the block changed
> + ??? Maybe we could track these changes separately, since they determine
> + what cleanups it makes sense to try on the block. */
Probably not worth the added effort. But it would depend on how
intrusive that change is.