This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
- From: "spop at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 24 Mar 2015 16:34:30 +0000
- Subject: [Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
- Auto-submitted: auto-generated
- References: <bug-65177-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #22 from Sebastian Pop <spop at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #21)
> Isn't the real issue here that the test for redirecting the edge is wrong?
You are right, the test for redirecting edges in copy_bbs is not sufficient for
jump-threading: it will redirect all edges pointing to copied blocks, whereas
what jump-threading expects is only redirect edges between consecutive blocks
on the path to be jump-threaded.
> If we're leaving the jump thread path, then we want those edges to reach
> their original targets. Thus merely testing if the destination is a
> duplicate block isn't the right test,
Right. Richi asked to let copy_bbs do its default behavior, redirecting edges
to all copied bbs, and fix up the edges that we don't want to redirect just
after the call to copy_bbs: that is implemented in the second patch I sent to
gcc-patches.
> we'd need to have the thread path and check if the outgoing edge is on the path or not.
>
> That may not be terribly easy to do in the current framework.
Note that the "region" of blocks we are passing to copy_bbs is the jump-thread
path in order of its execution: here is the code that creates the "region" just
before the call to copy_bbs:
for (unsigned int j = 0; j < len - 1; j++)
region[j] = (*path)[j]->e->dest;