https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #19 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.
>
> FAIL: path through PHI in bb8 (incoming bb:6) crosses loop
>
> But but, it does not exactly cross the loop as 5 (6) is not part of the loop
> but rather just 8.
Interesting. The restriction that tickles this is old legacy code in place
from way before I touched any of this:
// This is like path_crosses_loops in profitable_path_p but more
// restrictive, since profitable_path_p allows threading the
// first block because it would be redirected anyhow.
//
// If we loosened the restriction and used profitable_path_p()
// here instead, we would peel off the first iterations of loops
// in places like tree-ssa/pr14341.c.
bool profitable_p = m_path[0]->loop_father == e->src->loop_father;
if (!profitable_p && 0)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
" FAIL: path through PHI in bb%d (incoming bb:%d) crosses
loop\n",
e->dest->index, e->src->index);
continue;
}
I even annotated it because it seemed strange that it was more restrictive than
the generic restrictions in the backward threader.
It is very possible that we can remove this, as we have much more thorough loop
restrictions in place in the shared registry.
If you remove the above chunk, does it work? If so, I may have to test and
benchmark the change.
