On Thu, Nov 26, 2020 at 09:16:29AM +0000, Richard Biener wrote:
> > So, I really don't know if we want this or not, posting it for discussions.
>
> Is copysign (x, NaN) supposed to be well-defined? We'd stop folding
> this then, no?
Yes, we'd stop folding several cases with NaNs.
> I think the ABS_EXPR<x> < 0 to false folding is
> simply incomplete and should first check whether the operands are
> ordered? That said, NaN is nonnegative but NaN < 0 isn't false(?)
>
> So I don't think the patch is good.
Another possibility (if we have this optimization already in match.pd too)
would be to only optimize the < 0 case in GENERIC if !HONOR_NANS like
the >= 0 case is and only optimize it in GIMPLE. Though with the
default -ftrapping-math I think even optimizing qNaN < 0 to 0 is incorrect,
even that should raise invalid exception, shouldn't it?
So perhaps add a defaulted argument to the *nonnegative* APIs that would
say whether unordered is ok or not?
Jakub
