[PATCH V2] Practical Improvement to Double Precision Complex Divide

Patrick McGehearty patrick.mcgehearty@oracle.com
Wed Jun 10 22:34:09 GMT 2020


Joseph,
Thank you again for your prompt and insightful response.

It's now clear that I was engaged in wishful thinking that I only needed
to handle double precision in my proposed change. I understand now that
the text above the routine:
- - - - -
#if defined(L_divhc3) || defined(L_divsc3) || defined(L_divdc3) \
     || defined(L_divxc3) || defined(L_divtc3)
- - - - -
implies the same code is to be built for
L_divhc3  half precision
L_divsc3  single precision
L_divdc3  double precision
L_divxc3  extended precision
L_divtc3  quad precision

I will need expand my test suites for these other floating point formats
and do my best to understand how the libgcc build mechanisms work before
I'm ready to resubmit.

At first glance, assuming only one of the L_div?c3 names are defined at 
a time,
it seems like something like:

#ifdef L_divhc3
#define RBIG  (correct value for half precision)
#define RMIN  (correct value for half precision)
#define RMIN2 ...  (correct value for half precision)
#define RMINSCAL ... (correct value for half precision)
#endif
#ifdef L_divsc3
#define RBIG FLT_MAX
#define RMIN FLT_MIN
#define RMIN2 ...
#define RMINSCAL ...
#endif
...
would get the job done once I determine (and test) the correct
values for all formats.

- Patrick McGehearty


On 6/9/2020 6:11 PM, Joseph Myers wrote:
> On Wed, 10 Jun 2020, Patrick McGehearty wrote:
>
>> I see your point about other floating point formats.
>> According to the C standard, DOUBLE precision must
>> have a DBL_MAX of at least 1E+37. That is (slightly)
>> greater than 0x1.0p+63.
>>
>> Would
>> #define RMIN2 (0x1.0p-53)
>> #define RMINSCAL (0x1.0p+51)
>> be acceptable?
>> Those will be in range for any architecture that supports the C standard.
> But this code is used for different machine modes, not just double.  In
> particular, on Arm / AArch64 it may be used to build __divhc3.  And those
> constants are certainly outside the range of HFmode (IEEE binary16).
>
> I think you need to work out appropriate logic for what values are correct
> for a given machine mode, in terms of the parameters of that mode (maximum
> and minimum exponents etc.).  Then, if you can't represent the logic for
> determining those values (with the correct type, not hardcoding the
> absence of a suffix which would mean double) directly in C, see how
> c-cppbuiltin.c predefines extra macros if -fbuilding-libgcc (macros
> relating to built-in function suffixes and the number of bits in the
> mantissa of a floating-point mode are included there - it would certainly
> make sense to add more such macros if necessary).
>



More information about the Gcc-patches mailing list