Re: [tree-ssa] Grammar for GIMPLE condexprs

[law at redhat dot com]

In message <wvlptofl26j dot fsf at prospero dot boston dot redhat dot com>, Jason Merrill writes:
 >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.
Potentially, yes.  We don't want to be creating unnecessary temporaries or
other nodes if it can be easily avoided.

If we look beyond the missing hunks of infrastructure (C++ CFG and real
ssa->normal translator), then the next big thing IMHO is to evaluate
the quality of our gimple translators.

We know there's a significant compile-time and run-time penalty associated
with gimple translation right now.  Avoiding creation of unnecessary nodes
is one aspect of improving the translator.

Now I'm not implying that is Diego's motivation here, but the creation
of unnecessary nodes (of any type) should be avoided if we can do so
easily.

 >>> > 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.
Value numbering will allow us to catch this kind of stuff, even if the
variable names are different.  

Jeff