This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Allow FSM to thread single block cases too


On 10/14/2015 04:16 AM, Richard Biener wrote:
On Tue, Oct 13, 2015 at 2:52 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law <law@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]