[Bug tree-optimization/69991] New: missed tail merge optimization

vries at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Sat Feb 27 16:17:00 GMT 2016


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

            Bug ID: 69991
           Summary: missed tail merge optimization
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider testcase test.c:
...
void
foo (int c, int d, int *z, int *y)
{
  int res = 0;
  if (c)
    {
      *y = 0;
      if (d)
        {
          *z = 1;
          res = *y;
        }
    }
  else
    {
      *z = 1;
      res = *y;
    }
}
...

When compiled with -O2 -fno-tree-dce, tail-merge fails, due to this check in
find_duplicate:
...
  /* If the incoming vuses are not the same, and the vuse escaped into an
     SSA_OP_DEF, then merging the 2 blocks will change the value of the def,
     which potentially means the semantics of one of the blocks will be
changed.
     TODO: make this check more precise.  */
  if (vuse_escaped && vuse1 != vuse2)
    return;
...

Removing the check allows the testcase to be tail-merged, and the testcase
belonging the check (pr52734.c) still passes.  This is due to the fix for
PR62167. With a less conservative fix for PR62167, we'd still need this check
for pr52734.c. So it's not necessarily a good idea to remove the check now.

A quick fix would be to ignore defs with no uses in
gsi_advance_bw_nondebug_nonlocal, in the same way we ignore stmts with zero
operands. But the usability of such a fix would be limited.

Another option is to consider the TODO mentioned in the comment. The test-case
pr52734.c can actually safely be tail-merged, as long as the right bb is
chosen. If we can model the incoming vuse as a dependency for one bb, we should
be able to choose the right bb (the empty one with no depencencies).


More information about the Gcc-bugs mailing list