https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64823
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
So there's a few issues in play. But the major issue is we have forwarder
blocks which are not eliminated because we "Protect loop headers" (see
tree-cfgcleanup.c).
Those forwarder blocks might have PHIs, but no statements. The most
interesting threading opportunity in this case is threading to the loop exit
and thus completely bypassing the loop on some paths.
The code to prune the search space for jump threads pruned out those blocks.
That's a bit too aggressive as evidenced by this BZ. It's pretty easy to
detect these and special case them.
Second, we did not distinguish between a block with no statements and a block
where we did not process every statement. So a block with no statements was
interpreted as a partially processed block and thus not suitable for being a
joiner block in a jump threading path.
With those two fixed, we find the missed jump thread & bypass the loop when
reached via the o == 0 path out of the first conditional. That in turn allows
the compiler to recognize that within the loop "s" is always initialized
Patch in testing.
