Re: [patch] fold-const.c: Don't handle ASSERT_EXPR.

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Andrew,

> Could the code become alive any time soon, if so I would move the code.

>From the previous discussion, I am not convinced to keep ASSERT_EXPRs
beyond VRP (although keeping SSA_NAME_VALUE_RANGE seems very useful).

Even if we want to keep ASSERT_EXPRs beyond VRP (or even before VRP,
or during the entire SSA optimizations), I don't know what the current
handling of ASSERT_EXPRs is aimed at.

	tree c = fold (ASSERT_EXPR_COND (t));
	if (c == boolean_true_node)
	  return ASSERT_EXPR_VAR (t);
	else if (c == boolean_false_node)
	  return build (ASSERT_EXPR, TREE_TYPE (t), ASSERT_EXPR_VAR (t), c);
	else
	  return t;

ASSERT_EXPR_COND is supposed to tell us something that is true about
ASSERT_EXPR_VAR.  If ASSERT_EXPR_COND is trivially true, it's probably
OK to turn an ASSERT_EXPR into a copy statement.  Fine.

But if ASSERT_EXPR_COND is provably false, something is very wrong or
at least has changed significantly.  We probably no longer have a
statement that has been used to deduce an ASSERT_EXPR from.  Do we
really quietly fold such an ASSERT_EXPR into ASSERT_EXPR <var, 0> and
walk away?  What about SSA_NAME_VALUE_RANGE associated the SSA_NAME
that the result of ASSERT_EXPR is assigned to?  Note that VRP
considers this case as an internal compiler error.  Specifically, it
checks that ASSERT_EXPR_COND is never false at tree-vrp.c:1682.

So if we want to keep ASSERT_EXPRs beyond VRP, I think it's best to
leave the handling of ASSERT_EXPRs to passes that deal with
ASSERT_EXPRs.

Kazu Hirata