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 3ADD13858D20; Fri, 14 Apr 2023 18:10:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3ADD13858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1681495834;
	bh=3JzFDWM+op3xCr1PSZa80RDlb97AbpU2YeL/ZsyuPFQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=biUdiz9QaWZP2uMsFSeSnNOpPYJgbBTgOvuaOiBySpRRNxGPWWs+X0RsfZYZbrgz2
	 b6nzXQkv7Bru+Ev6RzdqZqY8gvOKwt4HV/POhlM+S5VQuEc6vF7ctfKhGjvJgBqHR6
	 AmkRSErU/V5lw03oLEvDhUYyy58pq88pbPXyHKh8=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109154] [13 regression] jump threading
 de-optimizes nested floating point comparisons
Date: Fri, 14 Apr 2023 18:10:32 +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: NEW
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-109154-4-79GJtgFhct@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 #48 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
for PHIs with 3+ arguments unless all the arguments but one are the same ev=
en
when not doing any smarts seems we emit one more COND_EXPR from what we cou=
ld.
The
      /* Common case.  */
case loop emits args_len COND_EXPRs, where to select one of the args_len
values, one should need only args_len - 1 COND_EXPRs.
So e.g. for the #c47 first testcase, we emit:
  _7 =3D a_10 < 0;
  _21 =3D a_10 >=3D 0;
  _22 =3D a_10 < e_11(D);
  _23 =3D _21 & _22;
  _26 =3D a_10 >=3D e_11(D);
  _27 =3D _21 & _26;
  _ifc__42 =3D _7 ? 1 : t_13;
  _ifc__43 =3D _23 ? t_13 : _ifc__42;
  t_6 =3D _27 ? 0 : _ifc__43;
Even when not trying to be smart on which predicate goes first and which go=
es
last (currently we only make sure that argument with most duplicates gets
last), I don't see why we should emit args_len COND_EXPRs, if we check just=
 the
last args_len - 1 predicates or first args_len - 1 predicates, when all the
predicates are false it should represent the argument that wasn't otherwise
picked.  So, the above without smart optimizations IMHO could be either
replaced with
  _ifc__42 =3D _23 ? t_13 : 1;
  t_6 =3D _27 ? 0 : _ifc__42;
or
  _ifc__42 =3D _23 ? t_13 : 0;
  t_6 =3D _7 ? 1 : _ifc__42;
etc.
But we really should also do the smart optimization, see through the
bb_predicates which one is BIT_AND_EXPRed with inversion of some other arg's
predicate and avoid those BIT_AND_EXPRs and redundant comparisons by sorting
them better.=