This is the mail archive of the gcc-bugs@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]

[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation


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;


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