From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 70BEB3858C32; Fri, 1 Mar 2024 09:44:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70BEB3858C32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709286286; bh=CFws8QPKBb+8fH+dqQfjaFBZvGD08lKSgkxuDWsMZ0I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OTq5UR9SjxwXzGgypl5YseXEvj9FBzmDxTGHLkSkXHk/OhKlnMcBOrDMnmEarFXYf yJZl3/+ESPivIDpVmJk2hSTk6+XAvzFOjq7iXu/6AwRAU7rmk5uhqtoOAn7tTdE8mF XSiEBBPCBic/rZbdg0bhFBvm9YBn468SmMxz0WmU= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7 Date: Fri, 01 Mar 2024 09:44:41 +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: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: 14.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=3D113441 --- Comment #32 from Richard Biener --- (In reply to Richard Sandiford from comment #31) > (In reply to Tamar Christina from comment #29) > > This works fine for normal gather and scatters but doesn't work for wid= ening > > gathers and narrowing scatters which only the pattern seems to handle. > I'm supposedly on holiday, so didn't see the IRC discussion, but: as I > remember it, there is no narrowing or widening for IFN gathers or scatters > as such, even for patterns. One vector's worth of offsets corresponds to > one vector's worth of data. But the widths of the data elements and the > offset elements can be different. Any sign or zero extension of a loaded > vector, or any operation to double or halve the number of vectors, is done > separately. Yep. The emulated gather/scatter and builtin paths do this widening/shorte= ning of the offset operand to what we expect on-the-fly. This support is missing from the IFN path which relies on patterns doing this. Having widening/shortening explicitly represented is of course better but using patterns for this has the unfortunate all-or-nothing effect (right no= w). I do hope with SLP only, where it's easier to insert/remove "stmts", we can delay "pattern recognition" in these cases eventually even up to vectorizable_* which would "simply" insert a widening/shortening operation into the SLP graph to make itself happy. In the mean time I think making the IFN path work also the same way as emuated/builtin would make sense. It's already half-way there.=