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 F0F6F3858288; Thu, 10 Aug 2023 21:54:44 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F0F6F3858288
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1691704484;
	bh=/9kFFvj4Y3eavrD3AiCw/kbh7x8YUIx2mEaDSaL0UjU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=omSlpRvqWpFSBKTNhLyfLpDUkvsGnBdTJC/3Ij/48+xsT6Rhm0Svc0byFTVyjoA+9
	 kVs8OmdB7it171/OORuBJPhFRNhS96MAuYOPWhvbgt2aPIPZbPJxJMb2MS18Qttvut
	 LMuw9AZGNurOBl8qTg5pBp0NvEZqLZ2/hCrog378=
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/110971] [14 Regression] ICE on valid code at
 -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261
Date: Thu, 10 Aug 2023 21:54:42 +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: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110971-4-mZtRiKUcz2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110971-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110971-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=3D110971

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The problem here is that the split conditional is predicted with probabilit=
y 0:

  if (b.0_1 > a.4_14)
    goto <bb 5>; [0.00%]
  else
    goto <bb 6>; [100.00%]

this is caused by jump threading;

  <bb 2> [local count: 118111600 freq: 1.000000]:
  a =3D 0;
  goto <bb 8>; [100.00%]

  <bb 3> [local count: 955630224 freq: 8.090909]:
  b.0_1 =3D b;
  if (b.0_1 > 2)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 477815112 freq: 4.045455]:
  c =3D 0;

  <bb 5> [local count: 955630224 freq: 8.090909]:
  if (b.0_1 > a.4_3)
    goto <bb 6>; [50.00%]
  else
    goto <bb 7>; [50.00%]

  <bb 6> [local count: 477815112 freq: 4.045455]:
  d =3D 0;

  <bb 7> [local count: 955630224 freq: 8.090909]:
  _2 =3D a.4_3 + 1;
  a =3D _2;

  <bb 8> [local count: 1073741824 freq: 9.090909]:
  a.4_3 =3D a;
  if (a.4_3 <=3D 1)
    goto <bb 3>; [89.00%]
  else
    goto <bb 9>; [11.00%]

So since b>2 implies a>2 we correctly thread but because both conditionals =
are
statically predicted with same probability we end up with probability 0.

  <bb 2> [local count: 118111600 freq: 1.000000]:
  a =3D 0;
  goto <bb 8>; [100.00%]

  <bb 3> [local count: 955630224 freq: 8.090909]:
  b.0_1 =3D b;
  if (b.0_1 > 2)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 477815112 freq: 4.045455]:
  c =3D 0;
  goto <bb 6>; [100.00%]

  <bb 5> [local count: 477815112 freq: 4.045455]:
  if (b.0_1 > a.4_3)
    goto <bb 6>; [0.00%]
  else
    goto <bb 7>; [100.00%]

  <bb 6> [local count: 477815112 freq: 4.045455]:
  d =3D 0;

  <bb 7> [local count: 955630224 freq: 8.090909]:
  _2 =3D a.4_3 + 1;
  a =3D _2;

  <bb 8> [local count: 1073741824 freq: 9.090909]:
  a.4_3 =3D a;
  if (a.4_3 <=3D 1)
    goto <bb 3>; [89.00%]
  else
    goto <bb 9>; [11.00%]


Threading commonly causes such probabilities 0 which may be harmful.
Loop splitting then preconditions the loop:

  <bb 2> [local count: 118111600 freq: 1.000000]:
  b.0_1 =3D b;
  if (b.0_1 > 0)
    goto <bb 19>; [0.00%]
  else
    goto <bb 20>; [100.00%]

That is bit of nonsence.  Since we expect loop to iterate and since we try =
to
keep it across preconditioning, we divide by 0.=