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 25 Mar 2003 13:33:26 -0500, Diego Novillo <dnovillo at redhat dot com> wrote:
> 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.
Is that really so horrible? AFAIK, the main reason for allowing
comparisons in the condition operand is so that we can translate them
directly into conditional jumps. If we can't do that anyway, I don't see
the harm in using a temporary.
> 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 should certainly match the code.
>> > 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.
How hard do you look for a matching predicate? I doubt that you'd see
T.225 ^ T.227 again, though you might see the original expression involving
a and b.
>
>> > 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.
It would in this case; you can pass anything with BOOLEAN_TYPE to
invert_truthvalue.
Jason