This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Patch for switch elimination (PR 54742)
- From: Steve Ellcey <sellcey at mips dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: David Malcolm <dmalcolm at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, <james dot greenhalgh at arm dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 14 Aug 2014 11:25:33 -0700
- Subject: Re: RFC: Patch for switch elimination (PR 54742)
- Authentication-results: sourceware.org; auth=none
- References: <1407865606 dot 2601 dot 74 dot camel at ubuntu-sellcey> <53EA5D74 dot 9020809 at redhat dot com> <47b32a49-298e-44f0-b84b-b8f664847a67 at email dot android dot com> <53EA7BD0 dot 1030901 at redhat dot com> <1407883486 dot 2601 dot 86 dot camel at ubuntu-sellcey> <20140813205519 dot GB23343 at instance-1 dot c dot bardezibar dot internal> <53EBD365 dot 4040100 at redhat dot com> <CAFiYyc2UKX74WKeE5e2tyKqmRbW5K4j4KbG0Fwgb+8iMYMTCiA at mail dot gmail dot com> <53ECDC13 dot 8090808 at redhat dot com> <1408032769 dot 28418 dot 183 dot camel at surprise> <53ECE1F9 dot 8050909 at redhat dot com>
On Thu, 2014-08-14 at 10:21 -0600, Jeff Law wrote:
> On 08/14/14 10:12, David Malcolm wrote:
> > On Thu, 2014-08-14 at 09:56 -0600, Jeff Law wrote:
> >> On 08/14/14 04:32, Richard Biener wrote:
> >>>> You'll note in a separate thread Steve and I discussed this during Cauldron
> >>>> and it was at my recommendation Steve resurrected his proof of concept
> >>>> plugin and started beating it into shape.
> >>>
> >>> But do we really want a pass just to help coremark?
> >> And that's the biggest argument against Steve's work. In theory it
> >> should be applicable to other FSMs, but nobody's come forth with
> >> additional testcases from real world applications.
> >
> > Maybe a regex library? Perhaps:
> > http://vcs.pcre.org/viewvc/code/trunk/pcre_dfa_exec.c?revision=1477 ?
> The key is that at least some states tell you at compile time what state
> you'll be in during the next loop iteration. Thus instead of coming
> around the loop, evaluating the switch condition, then doing the
> multi-way branch, we just directly jump to the case for the next iteration.
>
> I've never looked at the PCRE code to know if it's got cases like that.
>
> jeff
I compiled PCRE but it never triggered this optimization (even if I
bumped up the parameters for instruction counts and paths).
I understand the desire not to add optimizations just for benchmarks but
we do know other compilers have added this optimization for coremark
(See
http://community.arm.com/groups/embedded/blog/2013/02/21/coremark-and-compiler-performance) and the 13 people on the CC list for this bug certainly shows interest in having it even if it is just for a benchmark. Does 'competing against other compilers' sound better then 'optimizing for a benchmark'?
Steve Ellcey
sellcey@mips.com