This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Patch for switch elimination (PR 54742)

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:
> > ?
> 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 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]