Re: [PATCH] [ranger] x == -0.0 does not mean we can replace x with -0.0

[Jeff Law <jeffreyalaw@gmail.com>]

On 8/29/2022 8:26 AM, Aldy Hernandez wrote:
> On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>>
>> On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
>>> On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek <jakub@redhat.com> wrote:
>>>> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
>>>>> It seems to me we can do this optimization regardless, but then treat
>>>>> positive and negative zero the same throughout the frange class.
>>>>> Particularly, in frange::singleton_p().  We should never return TRUE
>>>>> for any version of 0.0.  This will keep VRP from propagating an
>>>>> incorrect 0.0, since all VRP does is propagate when a range is
>>>>> provably a singleton.  Also, frange::zero_p() shall return true for
>>>>> any version of 0.0.
>>>> Well, I think for HONOR_SIGNED_ZEROS it would be nice if frange was able to
>>>> differentiate between 0.0 and -0.0.
>>>> One reason is e.g. to be able to optimize copysign/signbit - if we can
>>>> prove that the sign bit on some value will be always cleared or always set,
>>>> we can fold those.
>>>> On the other side, with -fno-signed-zeros it is invalid to use
>>>> copysign/signbit on values that could be zero (well, nothing guarantees
>>>> whether the sign bit is set or clear), so for MODE_HAS_SIGNED_ZEROS &&
>>>> !HONOR_SIGNED_ZEROS it is best to treat contains_p as {-0.0,0.0} being
>>>> one thing (just not singleton_p) and not bother with details like whether
>>>> a range ends or starts with -0.0 or 0.0, either of them would work the same.
>>>> And for !MODE_HAS_SIGNED_ZEROS, obviously 0.0 can be singleton_p.
>>> *head explodes*
>>>
>>> Ok, I think I can add a zero property we can track (like we do for
>>> NAN), and set it appropriately at constant creation and upon results
>>> from copysign/signbit.  However, I am running out of time before
>>> Cauldron, so I think I'll just treat +-0.0 ambiguously for now, and do
>>> that as a follow-up.
>> We definitely want to be able to track +-0.0 and distinguish between
>> them.  IIRC there's cases where you can start eliminating comparisons
>> and arithmetic once you start tracking -0.0 state.
> Absolutely.  That was always the plan.  However, my goal was just to
> add relop stubs so others could flesh out the rest.  Alas, I'm way
> over that now :).  We're tracking NANs, endpoints, infinities, etc.
Well, we'll probably cycle back and forth a bit between the solver and 
figuring out what we need to track.

Related: I had a short email thread with Siddhesh and Carlos WRT the 
idea of putting in some __builtin_unreachables into the math routines.  
They're generally OK with it, though we do need to verify those 
conditionals aren't generating extra code.   So there's a potential path 
forward for that side of the problem as well.


>
> However, I'm hoping to forget as many floating point details, as fast
> as possible, as soon as I can ;-).
Actually FP isn't that bad -- I'd largely avoided it for decades, but 
didn't have a choice earlier this year.  And there's a lot more headroom 
for improvements in the FP space than the integer space IMHO.

Jeff