Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

[Jakub Jelinek <jakub@redhat.com>]

On Thu, Nov 26, 2020 at 03:13:22PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Nov 26, 2020 at 01:56:03PM -0000, Roger Sayle wrote:
> > My completely untested solution is the attached patch.  My apologies, I'm
> > not
> > even set up to compile things on the laptop that I'm composing this e-mail
> > on,
> > but my notes/proposals on tackling PR97965 are easier expressed as the
> > actual
> > suggested changes/edits.  [Forgive me if I've made a typo].
> 
> Ah, thanks, I wasn't aware of that function.
> Looking at the tree_expr_maybe_nan_p implementation, I wonder if:
>     case PLUS_EXPR:
>     case MINUS_EXPR:
>     case MULT_EXPR:
>       return !tree_expr_finite_p (TREE_OPERAND (x, 0))
>              || !tree_expr_finite_p (TREE_OPERAND (x, 1));
> shouldn't try harder, for + and minus, isn't
>       return (tree_expr_maybe_nan_p (TREE_OPERAND (x, 0))
> 	      || tree_expr_maybe_nan_p (TREE_OPERAND (x, 1))
> 	      || (!tree_expr_finite_p (TREE_OPERAND (x, 0))
> 		  && !tree_expr_finite_p (TREE_OPERAND (x, 1))));
> what we want to test?  I mean, if neither operand is a NaN and
> one of the operands is finite, then the result will be either finite
> or inf or -inf, but not NaN.  MULT_EXPR would presumably also need to
> rule out zeros (i.e. use the *nonzero* APIs too, on the other side
> +-inf * +-inf is not NaN).
> 
> Another thing, tree_expr_nonzero_warnv_p handles not just trees, but also
> GIMPLE, shouldn't these tree_expr_finite_p and tree_expr_maybe_nan_p APIs
> be also rewritten so that they can also handle SSA_NAMEs by walking the def
> chains?

Though, of course, both of this can be done incrementally later on.

I'll test your patch tonight.

	Jakub