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

[Aldy Hernandez <aldyh@redhat.com>]

On Mon, Aug 29, 2022 at 5:08 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> 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.

Absolutely.  Just working with basic relationals I've noticed that we
generate absolute garbage for some simple testcases.  I'm amazed what
makes it all the way to the assembly because we fail to fold simple
things.

Aldy