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
sell...@mips.com

Reply via email to