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
