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 C834E3858D37; Thu, 25 May 2023 13:01:40 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C834E3858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685019700;
	bh=1lVL7OYwWn6ejCXIx+iL96BIxAp4WHpMpGghTriSf6E=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=JSbAOnwQiSycXfJFxaKCjxA9uUmkogqMa1sqFns6NXn2V2wlZhSLFpCzeAkWof+3n
	 aUSJZsyZjUaRtaewg29fNuXCkTgpWuxlG6nuLR64OW37sogTk+U3Uf0RySbQ6uAAJM
	 DUnYgrsrRMUFWWfCQprjY7Z5/v1oyfP5YeVfjT/U=
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/109964] auto-vectorization of shift ignores integral
 promotions
Date: Thu, 25 May 2023 13:01:40 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.1.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo 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: 
Message-ID: <bug-109964-4-5jarAzucG5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109964-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109964-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=3D109964

--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.or=
g> ---
(In reply to Richard Biener from comment #3)
> So the bug in the vectorizer is that it does
>=20
> t.ii:14:5: note:   can narrow to signed:16 without loss of precision: _31=
 =3D
> 1 >> _30;
> t.ii:14:5: note:   only the low 16 bits of _30 are significant
>=20
> while that's correct that's not the proper constraint to check for in
> vect_recog_over_widening_pattern I think.  That has code to deal with
> overflow for plus/minus/mult but no defense against shifts
> (that's also not a vect_truncatable_operation_p, so maybe it should simply
> check that)
Like you say, vect_truncatable_operation_p already checks for operations
for which truncation is distributive.  But the function is supposed
to handle other cases too.  E.g. I think the current code is correct
for division.

But yeah, right shifts are an awkward case, because the defined
range of the second operand is much smaller than the range of the
type, and yet the defined range depends on the range of the type.
Sorry for not thinking about that at the time.=