This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[tree-ssa] gimple and fold_stmt
- From: Jan Hubicka <jh at suse dot cz>
- To: gcc at gcc dot gnu dot org, law at redhat dot com
- Date: Thu, 13 Nov 2003 01:25:53 +0100
- Subject: [tree-ssa] gimple and fold_stmt
Hi,
I am running into problem with fold_stmt turning:
if (T.1 != __complex__ (1.0e+0, 0.0))
into:
if (REALPART_EXPR <SAVE_EXPR <T.1>> != 1.0e+0 || IMAGPART_EXPR <SAVE_EXPR <T.1>> != 0.0)
That is no more generic. THis happens via fold:
/* If this is a comparison of complex values and either or both sides
are a COMPLEX_EXPR or COMPLEX_CST, it is best to split up the
comparisons and join them with a TRUTH_ANDIF_EXPR or TRUTH_ORIF_EXPR.
This may prevent needless evaluations. */
if ((code == EQ_EXPR || code == NE_EXPR)
&& TREE_CODE (TREE_TYPE (arg0)) == COMPLEX_TYPE
&& (TREE_CODE (arg0) == COMPLEX_EXPR
|| TREE_CODE (arg1) == COMPLEX_EXPR
|| TREE_CODE (arg0) == COMPLEX_CST
|| TREE_CODE (arg1) == COMPLEX_CST))
{
tree subtype = TREE_TYPE (TREE_TYPE (arg0));
tree real0, imag0, real1, imag1;
arg0 = save_expr (arg0);
arg1 = save_expr (arg1);
real0 = fold (build1 (REALPART_EXPR, subtype, arg0));
imag0 = fold (build1 (IMAGPART_EXPR, subtype, arg0));
real1 = fold (build1 (REALPART_EXPR, subtype, arg1));
imag1 = fold (build1 (IMAGPART_EXPR, subtype, arg1));
return fold (build ((code == EQ_EXPR ? TRUTH_ANDIF_EXPR
: TRUTH_ORIF_EXPR),
type,
fold (build (code, type, real0, real1)),
fold (build (code, type, imag0, imag1))));
}
Did we prepared some plan how to deal with issues like this?
Honza