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

[tree-ssa] Work around for an unfortunate fold-const vs. tree-optimizer interaction


Hi,

gcc.dg/tree-ssa/ssa-ccp-5.c is FAILing because we've already lost the ability to propagate the known value of a variable into the branches of the conditional even before reaching the tree optimizers (in fact, already in the front end).

The result is this:

(ssa-ccp-5.c.t22.ccp dump)
;; Function test55 (test55)

test55 (x, y)
{
  int u;
  _Bool T.3;
  _Bool T.2;
  _Bool T.1;

  T.1_2 = x_1 == 5
  T.2_4 = y_3 != 0
  T.3_5 = T.1_2 && T.2_4
  if (T.3_5)
    {
      goto <Ue800>;
    }
  else
    {
      goto <Ue880>;
    }
<Ue800>:;
  u_6 = x_1 + 22
  if (u_6 != 27)
    {
      goto <Ue900>;
    }
  else
    {
      goto <Ue880>;
    }
<Ue900>:;
  link_error ()   /* we scan the tree dump for this, and die.  */
  goto <Ue880>;
<Ue880>:;
<Uea80>:;
}

The problem is that we fail to propagate x == 5.

With the attached patch I get:

;; Function test55 (test55)

test55 (x, y)
{
  int u;

  goto <Ub780>;
<Ub780>:;
}

The difference is that we now replace the (x == 5 && y) with two new "if" statements, i.e. from the gimple dump:

  if (x == 5)
    {
      if (y != 0)
        {
          {
            u = x + 22;

So now we record (x == 5) in the avail_expr table and notice that u=27.
(Why is this test case called ssa-ccp anyway, this is a dominator opts testcase, really.)

Zdenek thinks we lose some CSE opportunities if we do it like this, but I think that being able to propagate these constants into the branches is more important, and that fold-const is really not the right place for this kind of early optimizations.  Besides, Honza had an ifcvt patch recently that would blow this piece of code away.

OTOH, there are perhaps other ways to teach the optimizers to deal with the current situation (looking at the exprs that appear on the rhs of the assignment to T.3_5???).  So I decided to just comment this piece of fold-const out for now.

Ideas?  OK for now? (booted-'n-tested on powerpc64)

Gr.
Steven

	* fold-const.c (fold_truthop): Comment out early branch
	simplification at least for now, it hurts the tree optimizers.

Index: fold-const.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.213.2.55
diff -c -3 -p -r1.213.2.55 fold-const.c
*** fold-const.c        30 Oct 2003 02:27:40 -0000      1.213.2.55
--- fold-const.c        6 Nov 2003 16:45:12 -0000
*************** fold_truthop (enum tree_code code, tree
*** 3801,3806 ****
--- 3801,3811 ----
                      truth_type, ll_arg, lr_arg);
      }

+ #if 0
+   /* Tree SSA FIXME:
+      This is disabled for tree-ssa, because on the branch we may actually
+      lose the opportunity to propagate constants into the branches of a
+      conditional.  */
    /* If the RHS can be evaluated unconditionally and its operands are
       simple, it wins to evaluate the RHS unconditionally on machines
       with expensive branches.  In this case, this isn't a comparison
*************** fold_truthop (enum tree_code code, tree
*** 3834,3839 ****
--- 3839,3845 ----

        return build (code, truth_type, lhs, rhs);
      }
+ #endif

    /* See if the comparisons can be merged.  Then get all the parameters for
       each side.  */


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