This is the mail archive of the 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] Loop header copying

> Hello,
> this patch moves the loop header copying pass from rtl to trees.  It is
> is neccessary to do it early since it increases effectivity of code
> motion optimizations.  It also kills a particulary ugly piece of rtl
> loop optimization code.

Very, very cool :)
So assuming that the sibling call patch will get re-approved soonish, we
are having only the dead RTL inliner and EH lowering passes killing CFG
in the early stages of compilation..
> Zdenek
> 	* (tree-ssa-loop.o): Add cfgloop.h and tree-inline.h
> 	dependency.
> 	* cfghooks.h (struct cfg_hooks): Add split_block_after_labels and
> 	move_block_after fields.
> 	(split_block_after_labels, move_block_after): New macros.
> 	* cfgloopmanip.c (create_preheader): Use split_block_after_labels.
> 	Do not update dominators when not asked to.
> 	(loop_split_edge_with): Do not update dominators when not asked to.
> 	* cfgrtl.c (rtl_split_block_after_labels): New.
> 	(rtl_cfg_hooks): Add rtl_split_block_after_labels.
> 	* jump.c (next_nonnote_insn_in_loop, duplicate_loop_exit_test,
> 	copy_loop_headers): Removed.
> 	* rtl.h (copy_loop_headers): Declaration removed.
> 	* toplev.c (rest_of_compilation): Do not call copy_loop_headers.
> 	* tree-cfg.c (create_bb): Create annotations for newly created
> 	blocks.
> 	(create_blocks_annotations): Removed.
> 	(build_tree_cfg): Call to create_blocks_annotations removed.
> 	(tree_split_edge): Let create_bb create the bb annotations.
> 	(tree_split_block_after_labels, tree_duplicate_bb,
> 	tree_move_block_after): New.
> 	(tree_cfg_hooks): Add split_block_after_labels.
> 	* tree-dump.c (dump_files): Add tree-copy-headers dump.
> 	* tree-flow.h (tree_duplicate_bb, copy_loop_headers): Declare.
> 	* tree-optimize.c (optimize_function_tree): Call copy_loop_headers.
> 	* tree-ssa-loop.c: Include cfgloop.h and tree-inline.h.
> 	(call_expr_p, should_duplicate_loop_header_p, copy_loop_headers): New.
> 	* tree.h (enum tree_dump_index): Add TDI_copy_headers.
> 	* doc/invoke.texi (-fdump-tree-copy-headers): Document.
> 	* testsuite/gcc.dg/tree-ssa/20030711-1.c: Update expected results.
> 	* testsuite/gcc.dg/tree-ssa/20030714-2.c: Ditto.
> 	* testsuite/gcc.dg/tree-ssa/copy-headers.c: New test.
> Index: cfghooks.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/cfghooks.h,v
> retrieving revision
> diff -c -3 -p -r1.1.2.6 cfghooks.h
> *** cfghooks.h	3 Nov 2003 17:47:35 -0000
> --- cfghooks.h	8 Dec 2003 20:28:03 -0000
> *************** struct cfg_hooks
> *** 51,56 ****
> --- 51,62 ----
>     /* Split basic block B after specified instruction I.  */
>     edge (*split_block) (basic_block b, void * i);
> +   /* Split basic block B immediatelly after labels.  */
> +   edge (*split_block_after_labels) (basic_block b);
> + 
> +   /* Move block B immediatelly after block A.  */
> +   void (*move_block_after) (basic_block b, basic_block a);
> + 

I see there is no entry for duplicate_block, but that is just an
ommision.  Please add it there (either by update of this patch or
incrementally depending whehter you will need new revision of it).
This is definitly something we want to hookize.

I am not very happy about move_block_after hook.  If it exists, it
should be somewhat unified with cfglayout way of reordering, but it
probably ought not be needed at first place.  We shall be completely
independent on the order of BBS on tree level...

Hmm perhaps it is because you want loops to be lienar regions at RTL
evel.  This problem seems to be more general as we do create basic
blocks in arbitrary order now so if we want to be serious about RTL loop
optimizer we need to reorder blocks during emiting the loop notes, but I
guess it is moot unless your plans to rewrite cfgloop fails miserably
(and that would be real disaster so I hope it won't happen). 
So perhaps we can keep it this way temporarily...


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