Re: [PATCH] Add set/get functions for negative infinity in real.*

[Aldy Hernandez <aldyh@redhat.com>]

On Fri, Aug 26, 2022 at 6:34 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 8/26/2022 10:24 AM, Aldy Hernandez wrote:
> > On Fri, Aug 26, 2022 at 6:08 PM Jeff Law via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >>
> >> On 8/23/2022 4:33 AM, Aldy Hernandez via Gcc-patches wrote:
> >>> For the frange implementation with endpoints I'm about to contribute,
> >>> we need to set REAL_VALUE_TYPEs with negative infinity.  The support
> >>> is already there in real.cc, but it is awkward to get at.  One could
> >>> call real_inf() and then negate the value, but I've added the ability
> >>> to pass the sign argument like many of the existing real.* functions.
> >>>
> >>> I've declared the functions in such a way to avoid changes to the
> >>> existing code base:
> >>>
> >>> // Unchanged function returning true for either +-INF.
> >>> bool real_isinf (const REAL_VALUE_TYPE *r);
> >>> // New overload to be able to specify the sign.
> >>> bool real_isinf (const REAL_VALUE_TYPE *r, int sign);
> >>> // Replacement function for setting INF, defaults to +INF.
> >>> void real_inf (REAL_VALUE_TYPE *, int sign = 0);
> >>>
> >>> Tested on x86-64 Linux.
> >>>
> >>> OK?
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>>        * real.cc (real_isinf): New overload.
> >>>        (real_inf): Add sign argument.
> >>>        * real.h (real_isinf): New overload.
> >>>        (real_inf): Add sign argument.
> >> Funny in that I've fairly recently had the desire to do something a bit
> >> similar.  Let's consider 0.5, which we have a dconsthalf, but we don't
> >> have dconstmhalf for -0.5.  To get that value I create a dconsthalf
> >> object and flip its sign.  Similarly for a variety of other special
> >> constants (particularly powers of two, but a few others as well).
> > Ugh, yeah.  I've been doing a lot of gymnastics in this space because
> > frange's will have REAL_VALUE_TYPE endpoints.
> In our case we have instructions that can make of various FP constants,
> some of which may be negative.  So we need to be able to recognize those
> constants.  Leading to having to do similar gymnastics as what you're doing.

It seems real.* needs some minor TLC.  For one, a lot of these
functions should be inlined.  I suppose it wasn't meant to be abused
the way we're about to in range-op-float.cc :-).

Thanks.
Aldy