Hi Richi,
Thanks for the comments!
on 2022/12/19 16:49, Richard Biener wrote:
> On Mon, Dec 19, 2022 at 9:12 AM Kewen.Lin <li...@linux.ibm.com> wrote:
>>
>> Hi,
>>
>> In function fold_convert_const_real_from_real, when the modes of
>> two types involved in fp conversion are the same, we can simply
>> take it as copy, rebuild with the exactly same TREE_REAL_CST and
>> the target type. It is more efficient and helps to avoid possible
>> unexpected signalling bit clearing in [1].
>>
>> Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu
>> and powerpc64{,le}-linux-gnu.
>>
>> Is it ok for trunk?
>
> But shouldn't
>
> double x = (double) __builtin_nans("sNAN");
>
> result in a quiet NaN?
IMHO, this treatment is still an tiny enhancement even without the
consideration on signalling nan.
I had the same doubt on if the bif should return qNaN without the
explicit option -fsignaling-nans, by checking the manual it says
"Compile code assuming that IEEE signaling NaNs may generate user-visible
traps during floating-point operations."
for the default -fno-signaling-nans, it doesn't exclude sNaN existence
clearly, and the generation of sNaN seems not to be like a normal floating
point operation which can cause trap. So I was inclined to believe that
the current behavior is expected. Besides the glibc uses this built-in
for SNAN macro, it seems not a good idea to return a qNaN for it at some
cases.
BR,
Kewen
>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608533.html
>>
>> gcc/ChangeLog:
>>
>> * fold-const.cc (fold_convert_const_real_from_real): Treat floating
>> point conversion to a type with same mode as copy instead of normal
>> convertFormat.
>> ---
>> gcc/fold-const.cc | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
>> index 114258fa182..eb4b6ca8820 100644
>> --- a/gcc/fold-const.cc
>> +++ b/gcc/fold-const.cc
>> @@ -2178,6 +2178,15 @@ fold_convert_const_real_from_real (tree type,
>> const_tree arg1)
>> REAL_VALUE_TYPE value;
>> tree t;
>>
>> + /* If the underlying modes are the same, simply treat it as
>> + copy and rebuild with TREE_REAL_CST information and the
>> + given type. */
>> + if (TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (arg1)))
>> + {
>> + t = build_real (type, TREE_REAL_CST (arg1));
>> + return t;
>> + }
>> +
>> /* Don't perform the operation if flag_signaling_nans is on
>> and the operand is a signaling NaN. */
>> if (HONOR_SNANS (arg1)
>> --
>> 2.27.0
