On Thu, Aug 21, 2014 at 11:41 AM, James Greenhalgh <james.greenha...@arm.com> wrote: > On Thu, Aug 21, 2014 at 09:57:56AM +0100, Richard Biener wrote: >> On Tue, Aug 19, 2014 at 10:39 PM, Steve Ellcey <sell...@mips.com> wrote: >> > Here is an official submission for the switch optimization described in >> > PR 54742. I have addressed the formatting/comment issues that were raised >> > and also added a test case based on comment #27 from PR 54742 and I fixed a >> > bug I found while doing benchmarking with SPEC2006 (the perl benchmark was >> > generating an ICE in a routine with multiple switch statements). >> > >> > I ran the benchmarking to see if I could find any more tests that are >> > helped like coremark is and while I found a number of benchmarks in >> > SPEC 2006 and EEMBC where the optimization is triggered, this optimization >> > generally didn't affect the performance of those benchmarks. The biggest >> > impact I could find was on the perl benchmark in SPEC where I saw around >> > a 0.4% improvement on a MIPS 74k. Not huge, but not nothing. >> > >> > So, OK to checkin? >> >> Without looking at the patch in detail what is the rationale for the >> pass placement (looks quite early)? I would have guessed that >> the pass could benefit from value-range analysis. >> >> Jeff, Steve is it possible to trigger the transform by simply >> "manually forcing" the right "path" jump-threads from >> inside VRP? That is, basically integrate the transform part >> with the existing jump threading framework but do an >> alternate discovery pass? > > This seems like what I tried to do last year with: > > https://gcc.gnu.org/ml/gcc-patches/2013-06/msg01121.html > > It turns Jeff's jump-threading code in to a strange franken-pass of bits and > pieces of detection and optimisation, and would need some substantial > reworking to fit in with Jeff's changes last Autumn, but if it is more > likely to be acceptable for trunk then perhaps we could look to revive it. > It would be nice to reuse the path copy code Jeff added last year, but I > don't have much intuition as to how feasible that is. > > Was this the sort of thing that you were imagining?
Yeah, didn't look too closely though. Richard. > Steve, Jeff? > > James > >> >> Thanks, >> Richard. >> >> > Steve Ellcey >> > sell...@mips.com >> > >> > >> > 2014-08-12 Steve Ellcey <sell...@mips.com> >> > >> > PR tree-opt/54742 >> > * Makefile.in (OBJS): Add tree-switch-shortcut.o. >> > * common.opt (ftree-switch-shortcut): New. >> > * opts.c (default_options_table): Add OPT_ftree_switch_shortcut. >> > * params.def (PARAM_MAX_SWITCH_INSNS): New. >> > (PARAM_MAX_SWITCH_PATHS): New. >> > * passes.def (pass_tree_switch_shortcut): New. >> > * timevar.def (TV_TREE_SWITCH_SHORTCUT): New. >> > * tree-pass.h (make_pass_tree_switch_shortcut): New. >> > * tree-switch-shortcut.c: New. >> > >> > >> > 2014-08-12 Steve Ellcey <sell...@mips.com> >> > >> > PR tree-opt/54742 >> > * gcc.dg/pr54742.c: New test. >> > >>
