From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14815 invoked by alias); 22 Mar 2006 15:06:58 -0000 Received: (qmail 14769 invoked by alias); 22 Mar 2006 15:06:54 -0000 Date: Wed, 22 Mar 2006 15:06:00 -0000 Message-ID: <20060322150654.14768.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: "richard dot guenther at gmail 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/msg02213.txt.bz2 List-Id: ------- Comment #11 from richard dot guenther at gmail dot com 2006-03-22 15:06 ------- Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller 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. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829