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] fwprop, updated patch and SPEC results


On Fri, 3 Nov 2006, Paolo Bonzini wrote:
> 2006-11-03  Paolo Bonzini  <bonzini@gnu.org>
> 	    Steven Bosscher  <stevenb.gcc@gmail.com>
>
>	* fwprop.c: New file.
>	* Makefile.in: Add fwprop.o.
>	* tree-pass.h (pass_rtl_fwprop, pass_rtl_fwprop_with_addr): New.
>	* passes.c (init_optimization_passes): Schedule forward propagation.
>	* rtlanal.c (loc_mentioned_in_p): Support NULL value of the second
>	parameter.
>	* timevar.def (TV_FWPROP): New.
>	* common.opt (-fforward-propagate): New.
>	* opts.c (decode_options): Enable forward propagation at -O2.
>	* gcse.c (one_cprop_pass): Do not run local cprop unless touching jumps.
>
>	* cse.c (fold_rtx_subreg, fold_rtx_mem, fold_rtx_mem_1, find_best_addr,
>	canon_for_address, table_size): Remove.
>	(new_basic_block, insert, remove_from_table): Remove references to
>	table_size.
>	(fold_rtx): Process SUBREGs and MEMs with equiv_constant, make
>	simplification loop more straightforward by not calling fold_rtx
>	recursively.
>	(equiv_constant): Move here a small part of fold_rtx_subreg,
>	do not call fold_rtx.  Call avoid_constant_pool_reference
>	to process MEMs.
>	* recog.c (canonicalize_change_group): New.
>	* recog.h (canonicalize_change_group): New.
>
>	* doc/invoke.texi (Optimization Options): Document fwprop.

This is OK for mainline.  Thanks.

To save Joseph and Gerald the effort of asking, could you also write
up a description of the new forward propagate pass for both passes.texi
and gcc-4.3/changes.html respectively.  I appreciate we're still early
in the process, but we can always update the descriptions later if
fwprop/CSE evolve significantly between now and stage 2.

This is a relatively large change, and I'd expect some form of
fallout from the RTL stream changes on some architectures.  If
you could be on the lookout for problems that would be good.

Once this patch is in the tree, I'll investigate the
loc_mentioned_in_p and canonicalize_change_group hunks.  It's
possible that these issues could be fixed in their respective
callers.  You've also grouped a number of related changes into
one big "merge" patch, and I'm curious of the impact/benefits
of each.  Perhaps in future, you could split things up into
smaller independent pieces, so that things improve iteratively?

Thanks again (especially for the updated SPEC results),

Roger
--


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