[PATCH] New inverted_operand_p function in fold-const.c

[Jeffrey A Law]

On Tue, 2004-09-07 at 09:17, Roger Sayle wrote:
> On Mon, 6 Sep 2004, Jeffrey A Law wrote:
> > On Sun, 2004-09-05 at 23:09, Roger Sayle wrote:
> > I don't think this is going to help with the overhead of
> > invert_truthvalue from the dominator optimizer.  DOM uses
> > invert_truthvalue to build expressions it can enter into
> > the hash tables as it walks through conditions.
> 
> Is the inverted condition hashed on?
Yes.  Basically every time we hit a COND_EXPR we record the
condition and its inverted condition into the hash table.

Given:
if (a > b)
   {
   }
 else
   {
   }


In the true arm we record
1 = (a > b)
0 = (a <= b)
0 = (a == b)  /* I think we record this, but I'm not absolutely
                 sure.  I'd have to verify in record_dominating_... */

In the false arm we record
1 = (a <= b)
0 = (a > b)

So, if we query the hash table for a > b in the true arm, we get back
"yes, and it has the value one".  Or we can query a <= b in the
true arm and get back "yes, it has the value zero".  Similarly for
the false block.

I guess we could change the hashing code and equality code to 
treat inverted conditions as equal, but indicate that the result
value needs to be inverted.  That would eliminate the need to
record both forms into the hash table.  Finding a way to integrate
that with record_dominating_conditions would be good as well since
record_dominating_conditions creates multiple tree nodes to enter
into the hash tables as well.


> Is it the call to invert_truthvalue in dom_opt_finalize_block or
> the call in get_eq_expr_value that's the most problematic?
Unclear -- I haven't had the time to evaluate one vs the other.
There's a distinct possibility that we can throttle back the
dom_opt_finalize_block version now that we've fixed some buglets
in get_eq_expr_value and its callers.

> 
> In dom_opt_finalize block are we sure the value "inverted" is not
> partially dead at the point we call invert_truthvalue?  It isn't
> immediately clear for a quick scan of the code that we're not
> sometimes calling invert_truthvalue and then never using the result
> if neither the true_edge or false_edge is dominated by bb or has
> phi_nodes?  Making this evaluation lazy might help; by adding
> 
> 	if (inverted == NULL_TREE)
> 	  inverted = invert_truthvalue (cond);
> 
> inside the two TREE_CODE_CLASS (cond_code) == '<' tests.
Yea, that might help a little as well.  

jeff
> --