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 94832385AC37; Wed, 30 Jun 2021 10:36:02 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 94832385AC37
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/101267] [12 Regression] ICE in
 vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2
Date: Wed, 30 Jun 2021 10:36:02 +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: 12.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-101267-4-plprKfBMgL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101267-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101267-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: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2021 10:36:02 -0000

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

--- Comment #5 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.or=
g> ---
(In reply to Richard Biener from comment #4)
> So we're having
>=20
> (gdb) p debug (slp_node)
> t.f90:1:21: note: node 0x39fbbc0 (max_nunits=3D2, refcnt=3D1)
> t.f90:1:21: note: op template: _144 =3D .MASK_LOAD (_143, 32B, _142);
> t.f90:1:21: note:       stmt 0 _144 =3D .MASK_LOAD (_143, 32B, _142);
> t.f90:1:21: note:       stmt 1 _146 =3D .MASK_LOAD (_145, 32B, _142);
> t.f90:1:21: note:       children 0x39fbc48
>=20
> where vectorizable_load invokes
>=20
> 8500              if (!vect_check_scalar_mask (vinfo, stmt_info, mask,
> &mask_dt,
> 8501                                           &mask_vectype))
> 8502                return false;
>=20
> but the SLP child is
>=20
> (gdb) p debug ((slp_tree)0x39fbc48)
> t.f90:1:21: note: node (external) 0x39fbc48 (max_nunits=3D1, refcnt=3D1)
> t.f90:1:21: note:       { _142, _142 }
>=20
> so it won't have a vector type set.  In fact vect_check_scalar_mask doesn=
't
> seem to be prepared for SLP at all - we're lucky it "works" but then most
> definitely it won't for externals.  You'll note that the SLP variant for
> vect_is_simple_use won't be applicable here since we only have SLP
> representations for the mask operand which isn't even the first one.
Seems like we should have a way of representing this kind of situation
though.  It doesn't seem unreasonable to have some operands (and especially
call arguments) that don't need to be vectorised.

Maybe a =E2=80=9Cfix=E2=80=9D for now might be to pass separate SLP and non=
-SLP operand
numbers to vect_is_simple_use.=