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

[Jeff Law <jeffreyalaw@gmail.com>]

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