public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: HAO CHEN GUI <guihaoc@linux.ibm.com>
To: Aldy Hernandez <aldyh@redhat.com>, Mikael Morin <morin-mikael@orange.fr>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	David <dje.gcc@gmail.com>, "Kewen.Lin" <linkw@linux.ibm.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	Jakub Jelinek <jakub@redhat.com>,
	"MacLeod, Andrew" <amacleod@redhat.com>
Subject: Re: [PATCHv2] Value range: Add range op for __builtin_isfinite
Date: Tue, 14 May 2024 10:16:46 +0800	[thread overview]
Message-ID: <84f6fdd5-74d2-45fb-89b3-574a79a55308@linux.ibm.com> (raw)
In-Reply-To: <CAGm3qMU-AQf_=GC_Shbdn6Yv5PrLuLq2gF7F_nuE2uPQs9PkWQ@mail.gmail.com>

Hi Aldy,
  Thanks for your review comments.

在 2024/5/13 19:18, Aldy Hernandez 写道:
> On Thu, May 9, 2024 at 10:05 AM Mikael Morin <morin-mikael@orange.fr> wrote:
>>
>> Hello,
>>
>> Le 07/05/2024 à 04:37, HAO CHEN GUI a écrit :
>>> Hi,
>>>    The former patch adds isfinite optab for __builtin_isfinite.
>>> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
>>>
>>>    Thus the builtin might not be folded at front end. The range op for
>>> isfinite is needed for value range analysis. This patch adds them.
>>>
>>>    Compared to last version, this version fixes a typo.
>>>
>>>    Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
>>> regressions. Is it OK for the trunk?
>>>
>>> Thanks
>>> Gui Haochen
>>>
>>> ChangeLog
>>> Value Range: Add range op for builtin isfinite
>>>
>>> The former patch adds optab for builtin isfinite. Thus builtin isfinite might
>>> not be folded at front end.  So the range op for isfinite is needed for value
>>> range analysis.  This patch adds range op for builtin isfinite.
>>>
>>> gcc/
>>>       * gimple-range-op.cc (class cfn_isfinite): New.
>>>       (op_cfn_finite): New variables.
>>>       (gimple_range_op_handler::maybe_builtin_call): Handle
>>>       CFN_BUILT_IN_ISFINITE.
>>>
>>> gcc/testsuite/
>>>       * gcc/testsuite/gcc.dg/tree-ssa/range-isfinite.c: New test.
>>>
>>> patch.diff
>>> diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
>>> index 9de130b4022..99c511728d3 100644
>>> --- a/gcc/gimple-range-op.cc
>>> +++ b/gcc/gimple-range-op.cc
>>> @@ -1192,6 +1192,56 @@ public:
>>>     }
>>>   } op_cfn_isinf;
>>>
>>> +//Implement range operator for CFN_BUILT_IN_ISFINITE
>>> +class cfn_isfinite : public range_operator
>>> +{
>>> +public:
>>> +  using range_operator::fold_range;
>>> +  using range_operator::op1_range;
>>> +  virtual bool fold_range (irange &r, tree type, const frange &op1,
>>> +                        const irange &, relation_trio) const override
>>> +  {
>>> +    if (op1.undefined_p ())
>>> +      return false;
>>> +
>>> +    if (op1.known_isfinite ())
>>> +      {
>>> +     r.set_nonzero (type);
>>> +     return true;
>>> +      }
>>> +
>>> +    if (op1.known_isnan ()
>>> +     || op1.known_isinf ())
>>> +      {
>>> +     r.set_zero (type);
>>> +     return true;
>>> +      }
>>> +
>>> +    return false;
>> I think the canonical API behaviour sets R to varying and returns true
>> instead of just returning false if nothing is known about the range.
> 
> Correct.  If we know it's varying, we just set varying and return
> true.  Returning false is usually reserved for "I have no idea".
> However, every caller of fold_range() should know to ignore a return
> of false, so you should be safe.

So it's better to set varying here and return true?
> 
>>
>> I'm not sure whether it makes any difference; Aldy can probably tell.
>> But if the type is bool, varying is [0,1] which is better than unknown
>> range.
> 
> Also, I see you're setting zero/nonzero.  Is the return type known to
> be boolean, because if so, we usually prefer to one of:
The return type is int. For __builtin_isfinite, the result is nonzero when
the float is a finite number, 0 otherwise.

> 
> r = range_true ()
> r = range_false ()
> r = range_true_and_false ();
> 
> It doesn't matter either way, but it's probably best to use these as
> they force boolean_type_node automatically.
> 
> I don't have a problem with this patch, but I would prefer the
> floating point savvy people to review this, as there are no members of
> the ranger team that are floating point experts :).
> 
> Also, I see you mention in your original post that this patch was
> needed as a follow-up to this one:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> 
> I don't see the above patch in the source tree currently:
Sorry, I may not express it clear. I sent a series of patches for review.
Some patches depend on others. The patch I mentioned is a patch also
under review.

Here is the list of the series of patches. Some of them are generic, and
others are rs6000 specific.

[PATCH] Value Range: Add range op for builtin isinf
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html

[patch, rs6000] Implement optab_isinf for SFmode, DFmode and TFmode
[PR97786]
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648304.html

[Patch] Builtin: Fold builtin_isinf on IBM long double to builtin_isinf
on double [PR97786]
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648433.html

[PATCH] Optab: add isfinite_optab for __builtin_isfinite
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html

[PATCHv2] Value range: Add range op for __builtin_isfinite
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650857.html

[PATCH-2, rs6000] Implement optab_isfinite for SFmode, DFmode and TFmode
[PR97786]
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649346.html

[PATCH-3] Builtin: Fold builtin_isfinite on IBM long double to
builtin_isfinite on double [PR97786]
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649351.html

[PATCH] Optab: add isnormal_optab for __builtin_isnormal
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649366.html

[PATCH-4, rs6000] Implement optab_isnormal for SFmode, DFmode and
TFmode [PR97786]
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649368.html

> 
> Thanks.
> Aldy
> 
>>
>>> +  }
>>> +  virtual bool op1_range (frange &r, tree type, const irange &lhs,
>>> +                       const frange &, relation_trio) const override
>>> +  {
>>> +    if (lhs.zero_p ())
>>> +      {
>>> +     // The range is [-INF,-INF][+INF,+INF] NAN, but it can't be represented.
>>> +     // Set range to varying
>>> +     r.set_varying (type);
>>> +     return true;
>>> +      }
>>> +
>>> +    if (!range_includes_zero_p (&lhs))
>>> +      {
>>> +     nan_state nan (false);
>>> +     r.set (type, real_min_representable (type),
>>> +            real_max_representable (type), nan);
>>> +     return true;
>>> +      }
>>> +
>>> +    return false;
>> Same here.
>>
>>> +  }
>>> +} op_cfn_isfinite;
>>> +
>>>   // Implement range operator for CFN_BUILT_IN_
>>>   class cfn_parity : public range_operator
>>>   {
>>
> 
Thanks
Gui Haochen

  reply	other threads:[~2024-05-14  2:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07  2:37 HAO CHEN GUI
2024-05-09  8:03 ` Mikael Morin
2024-05-09  8:47   ` HAO CHEN GUI
2024-05-09 19:09     ` Mikael Morin
2024-05-14 18:45     ` Andrew MacLeod
2024-05-15  6:01       ` HAO CHEN GUI
2024-05-13 11:18   ` Aldy Hernandez
2024-05-14  2:16     ` HAO CHEN GUI [this message]
2024-05-14 15:51       ` Andrew MacLeod
2024-05-14 15:57 ` Jakub Jelinek
2024-05-15  2:42   ` HAO CHEN GUI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84f6fdd5-74d2-45fb-89b3-574a79a55308@linux.ibm.com \
    --to=guihaoc@linux.ibm.com \
    --cc=aldyh@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=linkw@linux.ibm.com \
    --cc=morin-mikael@orange.fr \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).