From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id D122F396E84A; Thu,  8 Dec 2022 16:24:26 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D122F396E84A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670516666;
	bh=4TfR4E0s3EYaVXYzKJGLR//yH7OB/itH7eL2qRnE3N8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=g4PD5Q/eenXhMHkhAxqz+hDN4mjig/kcR5n47enkx41JocNJ4DPUty2Dy68s0GDi/
	 GQ2d+7h8836wYmVl+LZkUP1+YtXwJ7to2/wf4AiqO+UPVPZbY3/0cOel1xWMa2kdVF
	 udSd312Ib2j8vMr2rF1Dd7Q+igiBdOBQ7M5pgg9s=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107569] [13 Regression] Failure to optimize
 std::isfinite since r13-3596
Date: Thu, 08 Dec 2022 16:24:26 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107569-4-oaJ1PYBiS0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107569-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107569-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107569

--- Comment #40 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The current state of #c0 testcase is that bar is actually optimized into re=
turn
1;
Folding statement: .ASSUME (_Z3bard._assume.0, x_1(D));
_Z3bard._assume.0 assume inferred range of x_1(D) (param x) =3D [frange] do=
uble
[-1.79769313486231570814527423731704356798070567525844996599e+308
(-0x0.fffffffffffff8p+1024), 1.7976931
3486231570814527423731704356798070567525844996599e+308
(0x0.fffffffffffff8p+1024)]
during vrp1 and
Folding statement: _4 =3D _3 u>
1.79769313486231570814527423731704356798070567525844996599e+308;
Queued stmt for removal.  Folds to: 0

It is correct to optimize the comparison even with -ftrapping-math -
comparisons only
emit exceptions on NaNs, the quiet ones like u> even just on sNaNs, and the
range proves that the non-constant operand is never a NAN and the other isn=
't
either (it is constant).

On the other side, foo isn't optimized.
  # RANGE [frange] double [0.0 (0x0.0p+0), +Inf] +NAN
  _6 =3D ABS_EXPR <x_3(D)>;
  _4 =3D _6 u> 1.79769313486231570814527423731704356798070567525844996599e+=
308;
  _8 =3D ~_4;
  if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  __builtin_unreachable ();

  <bb 4> :
  # RANGE [frange] double [0.0 (0x0.0p+0), +Inf] +NAN
  _9 =3D ABS_EXPR <x_3(D)>;
  _10 =3D _9 u> 1.79769313486231570814527423731704356798070567525844996599e=
+308;
  _11 =3D ~_10;
  return _11;
is turned by fre1 into:
  _6 =3D ABS_EXPR <x_3(D)>;
  _4 =3D _6 u> 1.79769313486231570814527423731704356798070567525844996599e+=
308;
  _8 =3D ~_4;
  if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  __builtin_unreachable ();

  <bb 4> :
  return _8;
and while e.g. evrp figures correctly out that
2->3  (T) _6 :  [frange] double [+Inf, +Inf] +NAN
2->4  (F) x_3(D) :      [frange] double
[-1.79769313486231570814527423731704356798070567525844996599e+308
(-0x0.fffffffffffff8p+1024), 1.797693134862315708145274237317043567980705675
25844996599e+308 (0x0.fffffffffffff8p+1024)]
2->4  (F) _4 :  [irange] bool [0, 0] NONZERO 0x0
2->4  (F) _6 :  [frange] double [0.0 (0x0.0p+0),
1.79769313486231570814527423731704356798070567525844996599e+308
(0x0.fffffffffffff8p+1024)]
it doesn't do the extra step of figuring out that when _4 on the 2->4 edge =
must
be 0,
then _8 on that edge must be 1.
And, the finite range say for _6 or x_3(D) isn't stored into global state (=
if
there would be say some possibly not returning call between _6 definition a=
nd
uses or
for x_3(D) between start of function and the uses, we obviously couldn't st=
ore
it as a global range; in this case we could if we proved that isn't possibl=
e,
i.e. that if the function is reached then return _8; is reached too).
And then during vrp1 the same problem and __builtin_unreachable () is remov=
ed
with nothing noted anywhere.
Andrew, any thoughts?=