[Bug middle-end/81596] New: backwards threader misses simple copy within the same BB

["aldyh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81596

            Bug ID: 81596
           Summary: backwards threader misses simple copy within the same
                    BB
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aldyh at gcc dot gnu.org
  Target Milestone: ---

For the following simple testcase, the SSA backwards threader misses that xcopy
is a copy of a constant, because the definitions for both xcopy and x all occur
in the same BB, and the threader incorrectly thinks it will infinitely recurse.

void com (void);

void
foo()
{
  int x = 25;
  int xcopy = x;
  if (xcopy == 25)
        com();
}

./cc1 test.c -fdump-tree-all-details-alias -quiet -I/tmp -O2 -fno-tree-vrp
-fno-tree-ccp -fno-early-inlining -fno-forward-propagate -fno-tree-forwprop

As can be seen in the early threader dump (*.ethread), the compare is still
there, even though we can easily see it's a constant.  This happens because
fsm_find_control_statement_thread_paths() will mark the BB containing xcopy as
seen, and then recurse into
handle_assignment/fsm_find_control_statement_thread_paths again to find the
definition for xcopy.  Since the definition of xcopy also occurs in the same
basic block, and we've marked the BB as seen, we bail with no further
processing:

  /* Avoid infinite recursion.  */
  if (visited_bbs->add (var_bb))
    return;

This is obviously a highly contrived test whose options disable a lot of the
optimizations that would've caused the problem to go away.  As such, feel free
to mark as WONTFIX if this is something that will never happen in real life.