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
