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 ABE5A385AF8F; Fri,  7 Jul 2023 18:10:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ABE5A385AF8F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688753443;
	bh=6ndO7wTfuHt9U7+c7FIGkJUiIb3J9q84MODlwMFD/V0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=VV3KRK8DXa5zaogLug+lWYnYzEpllQqdwqeTDyp5sZ9gdXX1+UZfWuXBMk80A38CJ
	 o3fppIdTbrOcBM0KZLKKGqqaZkJvgirq6P5U6B5iHeMWau640TOL7yZun9o99PgHzh
	 gQbqYqbVW/s8/R6Xg/n9p4OO6jbc1gCtAof+iOfM=
From: "tnfchris at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109154] [13/14 regression] jump threading
 de-optimizes nested floating point comparisons
Date: Fri, 07 Jul 2023 18:10:43 +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: tnfchris at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tnfchris at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109154-4-VAyv4o9Gm3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109154-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109154-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=3D109154

--- Comment #59 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
I've sent two patches upstream this morning to fix the remaining ifcvt issu=
es:

https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623848.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623849.html

This brings us within 5% of GCC-12, but not all the way there,  the reason =
is
that since GCC-13 PRE behaves differently.

In GCC-12 after PRE we'd have the following CFG:

  <bb 15> [local count: 623751662]:
  _16 =3D distbb_79 * iftmp.1_100;
  iftmp.8_80 =3D 1.0e+0 - _16;
  _160 =3D chrg_init_75 * iftmp.8_80;

  <bb 16> [local count: 1057206200]:
  # iftmp.8_39 =3D PHI <iftmp.8_80(15), 1.0e+0(14)>
  # prephitmp_161 =3D PHI <_160(15), chrg_init_75(14)>
  if (distbb_79 < iftmp.0_96)
    goto <bb 17>; [50.00%]
  else
    goto <bb 18>; [50.00%]

  <bb 17> [local count: 528603100]:
  _164 =3D ABS_EXPR <prephitmp_161>;
  _166 =3D -_164;

  <bb 18> [local count: 1057206200]:
  # iftmp.9_40 =3D PHI <1.0e+0(17), 0.0(16)>
  # prephitmp_163 =3D PHI <prephitmp_161(17), 0.0(16)>
  # prephitmp_167 =3D PHI <_166(17), 0.0(16)>
  if (iftmp.2_38 !=3D 0)
    goto <bb 20>; [50.00%]
  else
    goto <bb 19>; [50.00%]

  <bb 19> [local count: 528603100]:

  <bb 20> [local count: 1057206200]:
  # iftmp.10_41 =3D PHI <prephitmp_167(18), prephitmp_163(19)>

That is to say, in both branches we always do the multiply, gimple-isel then
correctly turns this into a COND_MUL based on the mask.

Since GCC-13 PRE now does some extra optimizations:

  <bb 15> [local count: 1057206200]:
  # l_107 =3D PHI <l_84(21), 0(14)>
  _13 =3D lpos_x[l_107];
  x_72 =3D _13 - p_atom$x_81;
  powmult_73 =3D x_72 * x_72;
  distbb_74 =3D powmult_73 - radij_58;
  if (distbb_74 >=3D 0.0)
    goto <bb 17>; [59.00%]
  else
    goto <bb 16>; [41.00%]

  <bb 16> [local count: 433454538]:
  _165 =3D ABS_EXPR <chrg_init_70>;
  _168 =3D -_165;
  goto <bb 19>; [100.00%]

  <bb 17> [local count: 623751662]:
  _14 =3D distbb_74 * iftmp.1_101;
  iftmp.8_76 =3D 1.0e+0 - _14;
  if (distbb_74 < iftmp.0_97)
    goto <bb 18>; [20.00%]
  else
    goto <bb 19>; [80.00%]

  <bb 18> [local count: 124750334]:
  _162 =3D chrg_init_70 * iftmp.8_76;
  _164 =3D ABS_EXPR <_162>;
  _167 =3D -_164;

  <bb 19> [local count: 1057206200]:
  # iftmp.9_38 =3D PHI <1.0e+0(18), 0.0(17), 1.0e+0(16)>
  # iftmp.8_102 =3D PHI <iftmp.8_76(18), iftmp.8_76(17), 1.0e+0(16)>
  # prephitmp_163 =3D PHI <_162(18), 0.0(17), chrg_init_70(16)>
  # prephitmp_169 =3D PHI <_167(18), 0.0(17), _168(16)>
  if (iftmp.2_36 !=3D 0)
    goto <bb 21>; [50.00%]
  else
    goto <bb 20>; [50.00%]

That is to say, the multiplication is now compleletely skipped in one branc=
h,
this should be better for scalar code, but for vector we have to do the
multiplication anyway.

after ifcvt we end up with:

  _162 =3D chrg_init_70 * iftmp.8_76;
  _164 =3D ABS_EXPR <_162>;
  _167 =3D -_164;
  _ifc__166 =3D distbb_74 < iftmp.0_97 ? _167 : 0.0;
  prephitmp_169 =3D distbb_74 >=3D 0.0 ? _ifc__166 : _168;

instead of

  _160 =3D chrg_init_75 * iftmp.8_80;
  prephitmp_161 =3D distbb_79 < 0.0 ? chrg_init_75 : _160;
  _164 =3D ABS_EXPR <prephitmp_161>;
  _166 =3D -_164;
  prephitmp_167 =3D distbb_79 < iftmp.0_96 ? _166 : 0.0;

previously we'd make COND_MUL and COND_NEG and so don't need a VCOND in the
end,
now we select after the multiplication, so we only have a COND_NEG followed=
 by
a VCOND.

This is obviously worse, but I have no idea how to recover it.  Any ideas?=