This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] fwprop, updated patch and SPEC results
- From: Roger Sayle <roger at eyesopen dot com>
- To: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Steven Bosscher <stevenb dot gcc at gmail dot com>
- Date: Fri, 3 Nov 2006 13:16:08 -0700 (MST)
- Subject: Re: [PATCH] fwprop, updated patch and SPEC results
On Fri, 3 Nov 2006, Paolo Bonzini wrote:
> 2006-11-03 Paolo Bonzini <email@example.com>
> Steven Bosscher <firstname.lastname@example.org>
> * 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
> * 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
> (fold_rtx): Process SUBREGs and MEMs with equiv_constant, make
> simplification loop more straightforward by not calling fold_rtx
> (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),