[Bug tree-optimization/19804] New: Missed jump threading opportunity on "else" arm of COND_EXPR

[Bug tree-optimization/19804] New: Missed jump threading opportunity on "else" arm of COND_EXPR

[kazu at cs dot umass dot edu]

Consider:

int
foo (int a, int b)
{
  if (a == 0)
    if (b != 2)
      return 10;

  if (b == 1)
    return 10;

  return 20;
}

Here is t21.dom1:

foo (a, b)
{
  int D.1120;

<bb 0>:
  if (a_2 == 0) goto <L0>; else goto <L2>;

<L0>:;
  if (b_4 != 2) goto <L1>; else goto <L2>;

<L1>:;
  D.1120_7 = 10;
  goto <bb 6> (<L6>);

<L2>:;
  if (b_4 == 1) goto <L4>; else goto <L5>;

<L4>:;
  D.1120_6 = 10;
  goto <bb 6> (<L6>);

<L5>:;
  D.1120_5 = 20;

  # D.1120_1 = PHI <10(2), 10(4), 20(5)>;
<L6>:;
  return D.1120_1;

}

Note that edge from <L0> to <L2> can be threaded through L2.

This seems to be due to an artificial restriction in
tree-ssa-dom.c:dom_opt_finalize_block.

	      /* If we have a simple NAME = VALUE equivalency record it.
		 Until the jump threading selection code improves, only
		 do this if both the name and value are SSA_NAMEs with
		 the same underlying variable to avoid missing threading
		 opportunities.  */
	      if (lhs
		  && TREE_CODE (COND_EXPR_COND (last)) == SSA_NAME)
		record_const_or_copy (lhs, rhs);

This "if" should just say "if (lhs)".

But be careful though.  Making the above change seems to miss other jump
threading opportunities as far as I can tell from my coverage test.
I have yet to find a test case that would be less optimized with the above
change.

By the way, the comment above the "if" statement is just a cut-n-paste from
the "then" case.  It does not reflect what the "if" statement does though.

-- 
           Summary: Missed jump threading opportunity on "else" arm of
                    COND_EXPR
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kazu at cs dot umass dot edu
                CC: gcc-bugs at gcc dot gnu dot org,law at redhat dot com
OtherBugsDependingO 19794
             nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19804

[Bug tree-optimization/19804] Missed jump threading opportunity on "else" arm of COND_EXPR

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-07 04:50 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-07 04:50:55
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19804

[Bug tree-optimization/19804] Missed jump threading opportunity on "else" arm of COND_EXPR

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2005-02-07 06:45 -------
Here is a test case where a jump threading opportunity would be missed
if the change suggested in the original post were made:

void
foo (int *p)
{
  if (*p != 0)
    bar ();

  if (*p != 0)
    bar ();
}

Here is a tree dump right before the first DOM.

foo (p)
{
  int D.1120;

<bb 0>:
  D.1120_2 = *p_1;
  if (D.1120_2 != 0) goto <L0>; else goto <L1>;

<L0>:;
  bar ();

<L1>:;
  D.1120_3 = *p_1;
  if (D.1120_3 != 0) goto <L2>; else goto <L3>;

<L2>:;
  bar ();

<L3>:;
  return;

}

The change I suggested would record "D.1120_2 == 2" while following
edge from <L0> to <L2>.

Then th jump threading selection code figures out that

  D.1120_3 = *p_1;

is the same as

  D.1120_3 = 0;

via equality "D.1120_3 == D.1120_2".

For whatever reason, the jump threading selection code does not want to
see anything but SSA_NAME on the rhs.

At that point, DOM throws away this jump threading opportunity.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19804

[Bug tree-optimization/19804] Missed jump threading opportunity on "else" arm of COND_EXPR

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2005-02-07 06:46 -------
Note that PR 19516 is very closely related.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19804

[Bug tree-optimization/19804] Missed jump threading opportunity on "else" arm of COND_EXPR

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-02-14 21:02 -------
The updated jump thread selection code will catch this case and optimize it in
the appropriate way -- without causing us to miss other jump threading
opportunities :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19804

[Bug tree-optimization/19804] Missed jump threading opportunity on "else" arm of COND_EXPR

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-04-23 01:14 -------
Fixed now.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19804

[Bug tree-optimization/19804] Missed jump threading opportunity on "else" arm of COND_EXPR

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-04-25 05:07 -------
Fixed by:

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02426.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2005-
                   |                            |04/msg02426.html
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19804