James Greenhalgh wrote: > On Tue, Aug 19, 2014 at 09:39:56PM +0100, Steve Ellcey 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. > > For what it is worth, I see a nice (~4%) improvement in Crafty from > SPEC 2000. I haven't investigated too deeply, but at a first glance the > number of branch mispredictions has dropped just over 1%, as you > might hope from this optimisation. > > I can also attest to there being a number of places the optimisation is > triggered (with high enough parameters; I was running with > --param max-switch-paths=1000 --param max-switch-insns=10000), but like > you I don't see much measurable change in execution time.
Without change to the default params, I see the switch shortcut having a performance impact on both png and jpeg, compress and decompress mode. I think that's enough to remove the "benchmarketing" label from the switch shortcut transform. Sebastian
