On Fri, Aug 15, 2014 at 12:13 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Aug 14, 2014 at 8:25 PM, Steve Ellcey <sell...@mips.com> wrote: >> 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'? > > Well - as an open-source compiler we have the luxury to not care > about "benchmark compilers" ;) At least that's what our non-existant > sales-team told me. > > There are plenty "real" interpreters around which may have states > that deterministically forward to another state. If you optimize > those as well, fine. > > Btw - the patch doesn't contain a single testcase .... > > With coremark being "secret" what's the real-world testcase this > optimizes? Note that the benchmarks used in SPEC are usually > available and taken from real-world apps. I don't know coremark > at all, but from its name it sounds like sth like nullstone?
Ok, seems you can download coremark so I did that. The benchmark doesn't resemble any reasonable state machine as the "state" is simply compiler-visibly looping 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5... in a real state machine the next state would come from input (uninteresting) or be determined by a previous state (well - it is in the artificial case, but for all states which makes the switch moot). Thus this benchmark is so artificial that it isn't worth a special pass. I suppose the "expected" optimizaton is to un-obfuscate this into the non-state-machine this really is after peeling the first iterations to make 'seed' compile-time determinable (here I note the function comment that says it's important that 'seed' is _not_ compile-time known - hah, peeling is such a nice tool to "workaround" that idea). Stupid benchmarks. Richard. > Richard. > >> Steve Ellcey >> sell...@mips.com >>
