On Thu, 26 Nov 2020, Jakub Jelinek wrote: > 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?
Roger recently added some exhaustive changes in related areas, so let's see if he has anything to say here. Richard.
