This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Grammar for GIMPLE condexprs
On Tue, 2003-03-25 at 13:18, Jason Merrill wrote:
> > T.225 = a.224 < 0;
> > b.226 = (int)b;
> > T.227 = b.226 >= 0;
> > if (T.225 ^ T.227)
>
> is_simple_condexpr currently allows TRUTH_XOR_EXPR, which I assume is the
> code in the above tree, rather than the C ^, which is BIT_XOR_EXPR. This
> seems reasonable to me.
>
Yes. That '^' is TRUTH_XOR_EXPR. By moving TRUTH_AND_EXPR,
TRUTH_OR_EXPR and TRUTH_XOR_EXPR to is_simple_binary_expr I force the
gimplifier to create another temporary. It works, but at the expense of
another temporary. Ugh.
So, I should probably update the documented grammar to note that GIMPLE
also accepts TRUTH_XOR_EXPR, TRUTH_AND_EXPR and TRUTH_OR_EXPR as a
'relop'.
> > It shouldn't be too hard to change that to
> >
> > if ((T.225 ^ T.227) != 0)
> >
> > Right? Do you see any problems if I make that change?
>
> Why would you want to suppress just that comparison? I note that do_jump
> doesn't have special handling for TRUTH_AND_EXPR or TRUTH_OR_EXPR, either.
>
I'm not supressing comparisons. This pass registers known values for
predicates. When processing the THEN_CLAUSE of the if(), we associate
the predicate expression with the constant value 1. So, if the
predicate is used again inside the THEN_CLAUSE, it gets replaced with
1. Similarly for the ELSE_CLAUSE.
> > A pass that I'm working on needs to build TRUTH_NOT_EXPR <cond> and it's
> > failing when I call fold() on the generated tree (because
> > invert_truthvalue can't deal with VAR_DECLs).
>
> It should. Perhaps we should try to give boolean gimple temps BOOLEAN_TYPE
> even in C.
>
Would that stop fold() from getting all confused? If so, I'd rather do
this.
Diego.