On Wed, Oct 14, 2015 at 2:42 PM, Jeff Law <l...@redhat.com> wrote: > 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.
Like never threading a loop exit test to the loop header (but only to the exit). At least if it is the only exit in the loop (but maybe better for all exits). Richard. > jeff >
