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 76B0D3858C98; Wed, 28 Feb 2024 10:31:12 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 76B0D3858C98
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709116272;
	bh=U2/BCvIB5Q4qRvzKnY0gmzF9MtjZ5pS+DWnsAhLNL5k=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=CIUl7J5mNHBhAcmPGdXFlr8f7A9Spoej2DIcE8TYUOEmG3yZEKKGkLrJBDE3ALV1f
	 uPZWL6AwBnjL3bCLvRvnH7fq/uMzAQ8HpnphgSYi4AWZHhBph0W1vIQXxylcy1PUQ/
	 0NtwnLPx0BPkSP9GkloWx1csG+zKkI7LnPXPkIzM=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/114145] Missed optimization of loop deletion
Date: Wed, 28 Feb 2024 10:31:12 +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: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cf_reconfirmed_on bug_status everconfirmed
Message-ID: <bug-114145-4-9SMtk6Ozws@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114145-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114145-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=3D114145

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-28
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Store motion turns this into

  <bb 2> [local count: 10737416]:
  b_lsm.3_3 =3D _15(D);
  c_7 =3D a;

  <bb 3> [local count: 1063004408]:
  # c_12 =3D PHI <c_7(5), c_4(D)(2)>
  # i_13 =3D PHI <i_8(5), 0(2)>
  b_lsm.3_2 =3D c_12;
  i_8 =3D i_13 + 1;
  if (i_8 !=3D 700)
    goto <bb 5>; [98.99%]
  else
    goto <bb 4>; [1.01%]

  <bb 5> [local count: 1052266995]:
  goto <bb 3>; [100.00%]

  <bb 4> [local count: 10737416]:
  # b_lsm.3_11 =3D PHI <b_lsm.3_2(3)>
  b =3D b_lsm.3_11;
  return;

where ultimatively final value replacement fails because SCEV fails here:

(analyze_scalar_evolution
  (loop_nb =3D 1)
  (scalar =3D c_7)
(get_scalar_evolution=20=20
  (scalar =3D c_7)
  (scalar_evolution =3D ))
)=20
(instantiate_scev=20
  (instantiate_below =3D 2 -> 3)
  (evolution_loop =3D 1)
  (chrec =3D c_7)
  (res =3D c_7))
  (evolution_function =3D scev_not_known))

indeed there's no way to express the evolution of this induction variable
which has just two values.  Might be a simple thing to special case
in final value replacement though.  There we see just

  <bb 3> [local count: 1063004408]:
  # c_12 =3D PHI <c_7(5), c_4(D)(2)>
...
  <bb 4> [local count: 10737416]:
  # c_9 =3D PHI <c_12(3)>

so the final value is niter =3D=3D 0 ? c_4(D) : c_7.=