https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P1
--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
There's some rather simplistic accounting goofs in the FSM code which we'll
obviously want to fix. That's a good thing to fix, but doesn't make a big
difference for this test.
The tuning of the FSM code is very much geared towards the case where we thread
around the loop backedge through a multi-way branch (turning it into a
fall-thru or a trivial goto) -- which is very profitable. So we're willing to
allow a fair amount of block/statement copying to make that possible.
I think I need to do two things.
First, some of the logic in valid_jump_thread_path needs to move into
tree-ssa-threadbackward. In particular, it's important to know if we thread
through the latch, if there's a multi-way branch on the path and if a multi-way
branch is threaded. That shouldn't be terrible and has the nice effect that
we'll prune away some unprofitable paths earlier, saving a small bit of
compile-time & memory.
The second part is re-tuning. My first thought was to use the old jump
threader's tuning for # of statements to copy. Sadly, it's ever-so-slightly
too high to prevent the code explosion in this case.
But that's probably not good anyway -- the old threader is better at finding
jump threads that differ only in their starting edge (such paths can share the
duplicated path). So until the FSM backwards threader can share paths like
that, it needs to be less aggressive in terms of how much code it's willing to
copy.
So, the plan is to move the bits from valid_jump_thread_path that characterize
the path, then adjust the amount of copying we allow based on how the path is
characterized.
I'm going to go ahead and bump this to P1.
