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 E931E3858D33; Tue, 31 Jan 2023 11:44:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E931E3858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675165463;
	bh=Z8h2T+YbzYIQgFQANMetjcHDPfzG4vb9vqdhoZU8U0Q=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ibAYkDA8NR5W4nPxpuO/EA8oRxJkuD/cDUfAJmSEaJkzy/M/BiCFwaXPg9LxGCHnX
	 OR9LCy/2WwyGNQwy+/+CcFJXPF8xwE+g2JwNej/OJ6+g9j9iYN0z8/Oouxn3qsicC7
	 7jr+GQEVzODIP4fQ3vz9sbZYdBOKUuSD0dGLSakc=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/108583] [13 Regression] wrong code with vector division
 by uint16 at -O2
Date: Tue, 31 Jan 2023 11:44:23 +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.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: tnfchris at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108583-4-nK6SVIUy7U@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108583-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108583-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=3D108583

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 31 Jan 2023, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108583
>=20
> --- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
> (In reply to rsandifo@gcc.gnu.org from comment #9)
> > Are we sure this is a vectoriser vs. C vectors thing?
>=20
> it's not, the issue we're debating is how to fix it.
>=20
> As Richi pointed out https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D10858=
3#c4 we
> can fix the vectorizer case by adding a guard around the recog code in the
> vectorizer.
>=20
> But that only fixes the vectorizer, and Richi asked why that wasn't enoug=
h, to
> which I pointed out it's because intrinsics code hits it as well.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108583#c5
>=20
> This is why I mentioned that there are two ways to fix this:
>=20
> 1. We make the hook less general, and add checks in every place it is cal=
led.
> 2. We keep the hook general and pass enough context to the hook for it to
> decide how to optimize the division.

I don't think passing in for example the tree operand 0 helps, the
target appearantly wants to not specialize by the constant divided by
but instead also by the number divided (of we already know its type).

Do you plan to do SSA def pattern matching in the hook for this at
expand time?

As said, recognizing the special case and open-coding the full divison
in the vectorizer (or possibly even from RTL expansion) would be
another option here.=