On 10/14/2015 04:16 AM, Richard Biener wrote:
On Tue, Oct 13, 2015 at 2:52 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law <l...@redhat.com> wrote:
One of the cases that was missing in the FSM support is threading when the
path is a single block. ie, a control statement's output can be statically
determined just by looking at PHIs in the control statement's block for one
or incoming edges.
This is necessary to fix a regression if I turn off the old jump threader's
backedge support. Just as important, Jan has in the past asked about a
trivial jump threader to be run during early optimizations. Limiting the
FSM bits to this case would likely satisfy that need in the future.
I think he asked for trivial forward threads though due to repeated tests.
I hacked FRE to do this (I think), but maybe some trivial cleanup opportunities
are still left here. Honza?
This or other related patches in the range r228731:228774 has caused a quite
big jump in SPEC CPU 2000 binary sizes (notably 176.gcc - so maybe affecting
bootstrap as well, at -O3). Are you sure this doesn't re-introduce DOM
effectively peeling all loops once?
It's possible. I've actually got a patch in overnight testing that
introduces some of the heuristics to avoid mucking up loops to the FSM bits.
jeff
