public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>, Andrew MacLeod <amacleod@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC PATCH] range-op-float: Fix up op1_op2_relation of comparisons
Date: Tue, 11 Apr 2023 10:59:49 +0200	[thread overview]
Message-ID: <b9f5f55d-d055-16e1-a748-58f6064aeb28@redhat.com> (raw)
In-Reply-To: <ZDUYpbs+dY6ly8a1@tucnak>



On 4/11/23 10:21, Jakub Jelinek wrote:
> Hi!
> 
> This patch was what I've tried first before the currently committed
> PR109386 fix.  Still, I think it is the right thing until we have proper
> full set of VREL_* relations for NANs (though it would be really nice
> if op1_op2_relation could be passed either type of the comparison
> operands, or even better ranges of the two operands, such that
> we could choose if inversion of say VREL_LT is VREL_GE (if !MODE_HONOR_NANS
> (TYPE_MODE (type))) or rhs1/rhs2 ranges are guaranteed not to include
> NANs (!known_isnan && !maybe_isnan for both), or VREL_UNGE, etc.
> Anyway, the current state is that for the LE/LT/GE/GT comparisons
> we pretend the inverse is like for integral comparisons, which is
> true only if NANs can't appear in operands, while for UNLE/UNLT/UNGE/UNGT
> we don't override op1_op2_relation (so it always yields VREL_VARYING).
> 
> Though, this patch regresses the
> FAIL: gcc.dg/tree-ssa/vrp-float-6.c scan-tree-dump-times evrp "Folding predicate x_.* <= y_.* to 1" 1
> test, so am not sure what to do with it.  The test has explicit
> !isnan tests around it, so e.g. having the ranges passed to op1_op2_relation
> would also fix it.

I'll defer to Andrew on this, as he's the master of the relation oracle :).

Aldy

> 
> 2023-04-11  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* range-op-float.cc (foperator_lt::op1_op2_relation): Return
> 	VREL_VARYING instead of VREL_GE.
> 	(foperator_le::op1_op2_relation): Return VREL_VARYING instead of
> 	VREL_GT.
> 	(foperator_gt::op1_op2_relation): Return VREL_VARYING instead of
> 	VREL_LE.
> 	(foperator_ge::op1_op2_relation): Return VREL_VARYING instead of
> 	VREL_LT.
> 	(foperator_unordered_lt::op1_op2_relation,
> 	foperator_unordered_le::op1_op2_relation,
> 	foperator_unordered_gt::op1_op2_relation,
> 	foperator_unordered_ge::op1_op2_relation): New.
> 
> --- gcc/range-op-float.cc.jj	2023-04-01 09:32:02.635423345 +0200
> +++ gcc/range-op-float.cc	2023-04-03 10:42:54.000000000 +0200
> @@ -831,7 +831,10 @@ public:
>   		   relation_trio = TRIO_VARYING) const final override;
>     relation_kind op1_op2_relation (const irange &lhs) const final override
>     {
> -    return lt_op1_op2_relation (lhs);
> +    relation_kind ret = lt_op1_op2_relation (lhs);
> +    if (ret == VREL_GE)
> +      ret = VREL_VARYING; // Inverse of VREL_LT is VREL_UNGE.
> +    return ret;
>     }
>     bool op1_range (frange &r, tree type,
>   		  const irange &lhs, const frange &op2,
> @@ -947,6 +950,10 @@ public:
>   		   relation_trio rel = TRIO_VARYING) const final override;
>     relation_kind op1_op2_relation (const irange &lhs) const final override
>     {
> +    relation_kind ret = le_op1_op2_relation (lhs);
> +    if (ret == VREL_GT)
> +      ret = VREL_VARYING; // Inverse of VREL_LE is VREL_UNGT.
> +    return ret;
>       return le_op1_op2_relation (lhs);
>     }
>     bool op1_range (frange &r, tree type,
> @@ -1057,7 +1064,10 @@ public:
>   		   relation_trio = TRIO_VARYING) const final override;
>     relation_kind op1_op2_relation (const irange &lhs) const final override
>     {
> -    return gt_op1_op2_relation (lhs);
> +    relation_kind ret = gt_op1_op2_relation (lhs);
> +    if (ret == VREL_LE)
> +      ret = VREL_VARYING; // Inverse of VREL_GT is VREL_UNLE.
> +    return ret;
>     }
>     bool op1_range (frange &r, tree type,
>   		  const irange &lhs, const frange &op2,
> @@ -1177,7 +1187,10 @@ public:
>   		   relation_trio = TRIO_VARYING) const final override;
>     relation_kind op1_op2_relation (const irange &lhs) const final override
>     {
> -    return ge_op1_op2_relation (lhs);
> +    relation_kind ret = ge_op1_op2_relation (lhs);
> +    if (ret == VREL_LT)
> +      ret = VREL_VARYING; // Inverse of VREL_GE is VREL_UNLT.
> +    return ret;
>     }
>     bool op1_range (frange &r, tree type,
>   		  const irange &lhs, const frange &op2,
> @@ -1571,6 +1584,7 @@ class foperator_unordered_lt : public ra
>     using range_operator_float::fold_range;
>     using range_operator_float::op1_range;
>     using range_operator_float::op2_range;
> +  using range_operator_float::op1_op2_relation;
>   public:
>     bool fold_range (irange &r, tree type,
>   		   const frange &op1, const frange &op2,
> @@ -1599,6 +1613,13 @@ public:
>   	return true;
>         }
>     }
> +  relation_kind op1_op2_relation (const irange &lhs) const final override
> +  {
> +    relation_kind ret = lt_op1_op2_relation (lhs);
> +    if (ret == VREL_LT)
> +      ret = VREL_VARYING; // Should have been VREL_UNLT.
> +    return ret;
> +  }
>     bool op1_range (frange &r, tree type,
>   		  const irange &lhs,
>   		  const frange &op2,
> @@ -1682,6 +1703,7 @@ class foperator_unordered_le : public ra
>     using range_operator_float::fold_range;
>     using range_operator_float::op1_range;
>     using range_operator_float::op2_range;
> +  using range_operator_float::op1_op2_relation;
>   public:
>     bool fold_range (irange &r, tree type,
>   		   const frange &op1, const frange &op2,
> @@ -1710,6 +1732,13 @@ public:
>   	return true;
>         }
>     }
> +  relation_kind op1_op2_relation (const irange &lhs) const final override
> +  {
> +    relation_kind ret = le_op1_op2_relation (lhs);
> +    if (ret == VREL_LE)
> +      ret = VREL_VARYING; // Should have been VREL_UNLE.
> +    return ret;
> +  }
>     bool op1_range (frange &r, tree type,
>   		  const irange &lhs, const frange &op2,
>   		  relation_trio = TRIO_VARYING) const final override;
> @@ -1789,6 +1818,7 @@ class foperator_unordered_gt : public ra
>     using range_operator_float::fold_range;
>     using range_operator_float::op1_range;
>     using range_operator_float::op2_range;
> +  using range_operator_float::op1_op2_relation;
>   public:
>     bool fold_range (irange &r, tree type,
>   		   const frange &op1, const frange &op2,
> @@ -1817,6 +1847,13 @@ public:
>   	return true;
>         }
>     }
> +  relation_kind op1_op2_relation (const irange &lhs) const final override
> +  {
> +    relation_kind ret = gt_op1_op2_relation (lhs);
> +    if (ret == VREL_GT)
> +      ret = VREL_VARYING; // Should have been VREL_UNGT.
> +    return ret;
> +  }
>     bool op1_range (frange &r, tree type,
>   		  const irange &lhs, const frange &op2,
>   		  relation_trio = TRIO_VARYING) const final override;
> @@ -1900,6 +1937,7 @@ class foperator_unordered_ge : public ra
>     using range_operator_float::fold_range;
>     using range_operator_float::op1_range;
>     using range_operator_float::op2_range;
> +  using range_operator_float::op1_op2_relation;
>   public:
>     bool fold_range (irange &r, tree type,
>   		   const frange &op1, const frange &op2,
> @@ -1928,6 +1966,13 @@ public:
>   	return true;
>         }
>     }
> +  relation_kind op1_op2_relation (const irange &lhs) const final override
> +  {
> +    relation_kind ret = ge_op1_op2_relation (lhs);
> +    if (ret == VREL_GE)
> +      ret = VREL_VARYING; // Should have been VREL_UNGE.
> +    return ret;
> +  }
>     bool op1_range (frange &r, tree type,
>   		  const irange &lhs, const frange &op2,
>   		  relation_trio = TRIO_VARYING) const final override;
> 
> 	Jakub
> 


  reply	other threads:[~2023-04-11  8:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-11  8:21 Jakub Jelinek
2023-04-11  8:59 ` Aldy Hernandez [this message]
2023-04-11 20:58 ` Andrew MacLeod
2023-04-12 10:33   ` Jakub Jelinek
2023-04-12 14:21     ` Jakub Jelinek
2023-04-12 16:35       ` Bernhard Reutner-Fischer
2023-04-12 16:40         ` Jakub Jelinek

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=b9f5f55d-d055-16e1-a748-58f6064aeb28@redhat.com \
    --to=aldyh@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /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).