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 3F2383945C3A; Fri, 20 Mar 2020 07:14:56 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F2383945C3A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1584688496;
 bh=OJmNu2QG6lR0AeZUb8ptHhacAhKaHvayqLFyX/YEXjY=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=EwfOzn7TJAfWPO7AaR13qKRAcXqyBs/Q3fy/u2pOBu1NCRkUdkszVuP+1JBP5Cncr
 TRlG7llp6qVYSbE52abenNGAlWmzaZySEpjpyCzwv3SYEglpqeDAM7tqQ2FpJ8REwH
 nNw8Ih8hqRUDgd0UXAps7ZT26qhJwlVIi2zMYOdo=
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/94043] [9/10 Regression] ICE in
 superloop_at_depth, at cfgloop.c:78
Date: Fri, 20 Mar 2020 07:14:55 +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: 10.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linkw at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 9.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-94043-4-iEC56eCyIH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94043-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94043-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2020 07:14:56 -0000

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

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #5)
> On Fri, 20 Mar 2020, linkw at gcc dot gnu.org wrote:
>=20
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94043
> >=20
> > --- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
> > This was just exposed from my commit, it can also be reproduced without=
 my
> > commit but with -fno-vect-cost-model.
> >=20
> > Some loops we have for this case:
> > ;; Loop 1
> > ;;  header 3, latch 10
> > ;;  depth 1, outer 0
> > ;;  nodes: 3 10 8 23 25 34 35 26 29 32 33 38 4 11 37 31
> >=20
> > ;; Loop 2
> > ;;  header 4, latch 11
> > ;;  depth 2, outer 1
> > ;;  nodes: 4 11
> >=20
> > ;; Loop 4
> > ;;  header 26, latch 29
> > ;;  depth 2, outer 1
> > ;;  nodes: 26 29
> >=20
> >=20
> > When we are doing versioning for loop4 required for aliasing check, the=
 related
> >  scalar_loop_iters is based on e2.2_31, which is defined in BB 4, that =
is:
> >=20
> >   <bb 4> [local count: 4343773762]:
> >   # e2.2_31 =3D PHI <_15(11), 1(37)>
> >   # ivtmp_14 =3D PHI <ivtmp_23(11), 4(37)>
> >=20
> >=20
> > For the codes:
> >=20
> >         if ((def_bb =3D gimple_bb (SSA_NAME_DEF_STMT (USE_FROM_PTR (use=
_p))))
> >             && flow_bb_inside_loop_p (outermost, def_bb))
> >           outermost =3D superloop_at_depth (loop, bb_loop_depth (def_bb=
) + 1)
> >=20
> > bb_loop_depth is 2, the +1 make the assertion in superloop_at_depth fai=
l since
> > the current loop 4 only has the depth 2. I think the existing code has =
the
> > assumption that all operands in stmts of cond_expr_stmt_list are define=
d in
> > some outer loop of current, but the assumption breaks in this case.
> >=20
> > I guess the current scalar_loop_iters is valid? Then the fix can be:
>=20
> What is not valid I think is that e2.2_31 should have a loop-closed PHI
> node which would place it in an outer loop.  You'd have to see why
> either the loop-closed PHI is not present or why the aliasing check
> doesn't use that (it's more likely this)
>=20

Thanks for the confirmation Richi! There is a loop-closed PHI for it in bb =
33:

  <bb 4> [local count: 35145078524]:
  # e2.2_31 =3D PHI <_15(11), 1(31)>
  # ivtmp_14 =3D PHI <ivtmp_23(11), 4(31)>
  _11 =3D (integer(kind=3D8)) e2.2_31;
  _12 =3D _10 + _11;
  _13 =3D _12 + -7;
  hx[_13] =3D 0;
  _15 =3D e2.2_31 + 1;
  ivtmp_23 =3D ivtmp_14 - 1;
  if (ivtmp_23 =3D=3D 0)
    goto <bb 33>; [11.00%]
  else
    goto <bb 11>; [89.00%]

  <bb 33> [local count: 3865958617]:
  # _51 =3D PHI <_15(4)>

I'll further investigate why the scalar_loop_iters is constructed directly =
from
e2.2_31 instead of _51.=