Add set/get functions for negative infinity in real.*

  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.
---
 gcc/real.cc | 14 +++++++++++---
 gcc/real.h  |  5 ++++-
 2 files changed, 15 insertions(+), 4 deletions(-)
  

Another real.* tweak.  This time, adding a real_iszero() entry point
to match the real_isnegzero.  I could combine this patch with the
negative infinity one in this thread if y'all would prefer.

OK pending tests?

p.s. I'd really like to go and benchmark all this real.* stuff
(later), because I think we could inline a bunch of these functions in
the header file.

On Tue, Aug 23, 2022 at 12:33 PM Aldy Hernandez <aldyh@redhat.com> 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.
> ---
>  gcc/real.cc | 14 +++++++++++---
>  gcc/real.h  |  5 ++++-
>  2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/real.cc b/gcc/real.cc
> index 4e63b1449c5..f570ca8e85b 100644
> --- a/gcc/real.cc
> +++ b/gcc/real.cc
> @@ -1234,6 +1234,14 @@ real_isinf (const REAL_VALUE_TYPE *r)
>    return (r->cl == rvc_inf);
>  }
>
> +/* Determine whether a floating-point value X is infinite with SIGN.  */
> +
> +bool
> +real_isinf (const REAL_VALUE_TYPE *r, int sign)
> +{
> +  return real_isinf (r) && r->sign == sign;
> +}
> +
>  /* Determine whether a floating-point value X is a NaN.  */
>
>  bool
> @@ -2484,12 +2492,12 @@ dconst_sqrt2_ptr (void)
>    return &value;
>  }
>
> -/* Fills R with +Inf.  */
> +/* Fills R with Inf with SIGN.  */
>
>  void
> -real_inf (REAL_VALUE_TYPE *r)
> +real_inf (REAL_VALUE_TYPE *r, int sign)
>  {
> -  get_inf (r, 0);
> +  get_inf (r, sign);
>  }
>
>  /* Fills R with a NaN whose significand is described by STR.  If QUIET,
> diff --git a/gcc/real.h b/gcc/real.h
> index 845ef29e3a4..76360b603fb 100644
> --- a/gcc/real.h
> +++ b/gcc/real.h
> @@ -277,6 +277,9 @@ extern bool real_compare (int, const REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *)
>  /* Determine whether a floating-point value X is infinite.  */
>  extern bool real_isinf (const REAL_VALUE_TYPE *);
>
> +/* Determine whether a floating-point value X is infinite with SIGN.  */
> +extern bool real_isinf (const REAL_VALUE_TYPE *, int sign);
> +
>  /* Determine whether a floating-point value X is a NaN.  */
>  extern bool real_isnan (const REAL_VALUE_TYPE *);
>
> @@ -331,7 +334,7 @@ extern long real_to_target (long *, const REAL_VALUE_TYPE *, format_helper);
>  extern void real_from_target (REAL_VALUE_TYPE *, const long *,
>                               format_helper);
>
> -extern void real_inf (REAL_VALUE_TYPE *);
> +extern void real_inf (REAL_VALUE_TYPE *, int sign = 0);
>
>  extern bool real_nan (REAL_VALUE_TYPE *, const char *, int, format_helper);
>
> --
> 2.37.1
>
  

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).

Consider making the "sign" argument a boolean.  It's defined as a single 
bit bitfield in the real_value structure.   We don't want folks to pass 
in values outside [0..1] for the sign if we can easily avoid it:-)



jeff
  

On 8/26/2022 9:43 AM, Aldy Hernandez via Gcc-patches wrote:
> Another real.* tweak.  This time, adding a real_iszero() entry point
> to match the real_isnegzero.  I could combine this patch with the
> negative infinity one in this thread if y'all would prefer.
>
> OK pending tests?
>
> p.s. I'd really like to go and benchmark all this real.* stuff
> (later), because I think we could inline a bunch of these functions in
> the header file.
Same comments as the INF patch.

jeff
  

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.

>
> Consider making the "sign" argument a boolean.  It's defined as a single
> bit bitfield in the real_value structure.   We don't want folks to pass
> in values outside [0..1] for the sign if we can easily avoid it:-)

I was trying to follow all the other functions in real.cc which have
"int sign", though I suppose none of them are exported in the header
file.

OK pending tests?
Aldy
  

On Fri, Aug 26, 2022 at 6:09 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 8/26/2022 9:43 AM, Aldy Hernandez via Gcc-patches wrote:
> > Another real.* tweak.  This time, adding a real_iszero() entry point
> > to match the real_isnegzero.  I could combine this patch with the
> > negative infinity one in this thread if y'all would prefer.
> >
> > OK pending tests?
> >
> > p.s. I'd really like to go and benchmark all this real.* stuff
> > (later), because I think we could inline a bunch of these functions in
> > the header file.
> Same comments as the INF patch.

OK pending tests?
Aldy
  

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.
>   or
>
>> Consider making the "sign" argument a boolean.  It's defined as a single
>> bit bitfield in the real_value structure.   We don't want folks to pass
>> in values outside [0..1] for the sign if we can easily avoid it:-)
> I was trying to follow all the other functions in real.cc which have
> "int sign", though I suppose none of them are exported in the header
> file.
They probably pre-date using bool types in GCC.  Feel free to update 
them if you need a mindless task at some point.

>
> OK pending tests?
Of course.  I should have noted that with such a change it'd pre-approved.

jeff
  

On 8/26/2022 10:25 AM, Aldy Hernandez wrote:
> On Fri, Aug 26, 2022 at 6:09 PM Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>>
>> On 8/26/2022 9:43 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Another real.* tweak.  This time, adding a real_iszero() entry point
>>> to match the real_isnegzero.  I could combine this patch with the
>>> negative infinity one in this thread if y'all would prefer.
>>>
>>> OK pending tests?
>>>
>>> p.s. I'd really like to go and benchmark all this real.* stuff
>>> (later), because I think we could inline a bunch of these functions in
>>> the header file.
>> Same comments as the INF patch.
> OK pending tests?
Yes.
Jeff
  

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