From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5A2E73858D28; Mon, 30 Jan 2023 15:01:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A2E73858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675090864; bh=q692e9+kiaJSBDwsIBDOaFrJ/bdcx3zbRYgc8uIe/kg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=prtvaT3LcYwVEbDIDWFg0S4ObfgbyEno0Hy+ELMhCHskhs+2yhGT8C16d1ERwD8pE 56QGHb8ZjQi5Hbsjl7p4fLEZvlVCKpwqH8n6safNMkg19SgC5+BZAtHSDL4AYiXwDj LMUJ0sRBIikGRoxIeih0OrJopM+2Is1HHI0wYP2w= From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2 Date: Mon, 30 Jan 2023 15:01:03 +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: tnfchris at gcc dot gnu.org 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108583 --- Comment #5 from Tamar Christina --- > > The vectorizer has this context but since we didn't want a new IFN the= =20 > > context should instead be derivable in=20 > > targetm.vectorize.can_special_div_by_const hook. >=20 > The vectorizer doesn't check for a widened operand zero. In fact > "can_special_div_by_const" doesn't suggest that widening is required. Correct, at the moment the generalized so far as to be a generic div by constant operation. But the original sequence wanted to optimize a sequence that needs more context than what was given to it. > If the vectorizer checks that then why do we need another operand? Because the expansion gets triggered by intrinsics code as well: typedef unsigned __attribute__((__vector_size__ (16))) V; static __attribute__((__noinline__)) __attribute__((__noclone__)) V foo (V v, unsigned short i) { v /=3D i; return v; } It's invalid to do this particular decomposition we do in AArch64, but the = hook doesn't know this. Since the new IFN wasn't like we're just leaving the `/` alone in the vectorizer. But this means the expansion code, or the backend needs to be able to check the context in which we are expanding. We don't have an integer vector division operation. So the operation needs = to be decomposed. And if we decompose it, then the sequence becomes too long = for combine to match and we're back where we started.=