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

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Aug 15, 2014 at 12:13 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 8:25 PM, Steve Ellcey <sellcey@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
>> sellcey@mips.com
>>