This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Switch elimination pass for PR 54742
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Sebastian Pop <sebpop at gmail dot com>
- Cc: James Greenhalgh <james dot greenhalgh at arm dot com>, Steve Ellcey <sellcey at mips dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Thu, 21 Aug 2014 10:53:54 +0200
- Subject: Re: [Patch] Switch elimination pass for PR 54742
- Authentication-results: sourceware.org; auth=none
- References: <1408480796 dot 31355 dot 7 dot camel at ubuntu-sellcey> <20140820170410 dot GA24377 at arm dot com> <20140820202913 dot GA2691 at instance-1 dot c dot bardezibar dot internal>
On Wed, Aug 20, 2014 at 10:29 PM, Sebastian Pop <sebpop@gmail.com> wrote:
> 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.
Did you look at the actual code transformation the pass does to these?
(what is 'png' and 'jpeg'?) What's the code size impact?
Richard.
> Sebastian