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

[Roger Sayle <roger at eyesopen dot com>]

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?  i.e. are we relying on fold
and invert_truthvalue to canonicalize expressions so that we can
find matching conditions.

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?

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.

Roger
--