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: [patch] Avoid rescanning cfg in tree cfg cleanup


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.


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