From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13922 invoked by alias); 28 Mar 2006 19:14:02 -0000 Received: (qmail 13779 invoked by alias); 28 Mar 2006 19:13:59 -0000 Date: Tue, 28 Mar 2006 19:14:00 -0000 Message-ID: <20060328191359.13778.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "law at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-03/txt/msg02776.txt.bz2 List-Id: ------- Comment #13 from law at redhat dot com 2006-03-28 19:13 ------- Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller On Wed, 2006-03-22 at 16:06 +0100, Richard Guenther wrote: > On 3/22/06, Jeffrey A Law wrote: > > On Wed, 2006-03-22 at 12:14 +0100, Richard Guenther wrote: > > > On 3/21/06, Jeffrey A Law wrote: > > > > It turns out this specialized PHI optimization pass is as effective > > > > as running copy-prop and CCP on PHI nodes after DOM. Better yet, it > > > > is a teeny tiny slowdown compared to just running the stripped down > > > > copyprop. ie, for an almost unmeasurable slowdown we can do both > > > > constant and copy propagation instead of just copy propagation. > > > > > > This patch caused a compile-time regression from 139s to 143s, resp. > > > 192s to 197s (leafify) accounted by increases of operand scan / SSA incremental > > > and tree CCP times for compiling tramp3d. Also memory usage during compiling > > > went up from 655494 kB to 660626kB (this may be due to the VRP patch, though). > > > > > > Runtime of tramp3d did not improve but regress slightly (but that > > > might be in the > > > noise - we'll see). > > > > > > For this simple cleanup pass can you try updating SSA form manually please? > > I'm more than happy to look at it; however, be aware that if you're > > seeing increased time in CCP then either you're seeing some truly > > bizzarre secondary effect or your testing methodology is suspect. > > The patch did not affect CCP. In fact, the changes only affect > > passes which run *after* CCP in the optimization pipeline. > > struct tree_opt_pass pass_phi_only_cprop = > { > "phicprop", /* name */ > gate_dominator, /* gate */ > eliminate_degenerate_phis, /* execute */ > NULL, /* sub */ > NULL, /* next */ > 0, /* static_pass_number */ > TV_TREE_CCP, /* tv_id */ > PROP_cfg | PROP_ssa | PROP_alias, /* properties_required */ > 0, /* properties_provided */ > PROP_smt_usage, /* properties_destroyed */ > 0, /* todo_flags_start */ > TODO_cleanup_cfg | TODO_dump_func > | TODO_ggc_collect | TODO_verify_ssa > | TODO_verify_stmts | TODO_update_smt_usage > | TODO_update_ssa, /* todo_flags_finish */ > 0 /* letter */ > }; > > see tv_id - so I guess increased CCP times are expected. I've created a separate timevar for the phi-only cprop code so at least we can see how much time's taking. Note that while we should be seeing a small amount of time in phi-cprop, we should be seeing a reduction in TV_TREE_CCP and TV_TREE_COPY_PROP. Can you send me a recent tramp3d.ii file so that I can poke around and see if there's anything we can do about the compile time regression? Thanks, jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829