From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E94C1382E81F; Thu, 11 Mar 2021 13:03:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E94C1382E81F From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966 Date: Thu, 11 Mar 2021 13:03:16 +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: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 13:03:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97494 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #8 from Richard Biener --- The power7 failure with FAIL: gcc.dg/vect/vect-complex-5.c scan-tree-dump-times vect "vectorizing s= tmts using SLP" 2 Shows that alignment checking as done in get_group_load_store_type does not match what we later code-generate. The first group, storing into c[i].f1 =3D a1[i] + b1[i]; is said to be aligned while the second c[i].f2 =3D a2[i] + b2[i]; is said to be unaligned and thus unsupported. In reality both are VMAT_STRIDED_SLP which can end up with a variety of alignment requirements. In this case we emit a series of SImode stores to SImode aligned memory in both cases. Thus, static bool get_group_load_store_type (vec_info *vinfo, stmt_vec_info stmt_info, ... if (*memory_access_type =3D=3D VMAT_GATHER_SCATTER || *memory_access_type =3D=3D VMAT_ELEMENTWISE) *alignment_support_scheme =3D dr_unaligned_supported; else *alignment_support_scheme =3D vect_supportable_dr_alignment (vinfo, first_dr_info, false); is incomplete and misses special-casing of VMAT_STRIDED_SLP. For VMAT_ELEMENTWISE we seem to simply assume that element (scalar) misaligned accesses are OK (ISTR we reject non-element aligned vectorizatio= n), but with VMAT_STRIDED_SLP we eventually use SImode to access two HImode components which are not necessarily aligned according to SImode. There's the related bug where the alignment we compute for a vector DR is biased when the stride is negative and which also results in bogus alignment to be used for checks. ISTR I wrote somewhere that vectorizable_load/store analysis & costing should possibly simply run through a common code path for analysis and code generation (fending off actual stmt generation for analysis) to avoid this kind of disconnect between code gen assumptions and analysis parts. Thus the classical if (!vec_stmt) return early; approach isn't good for maintainance. That said, gcc.dg/vect/vect-complex-5.c is a missed optimization on !hw-misaligned targets, thus I'm going to XFAIL it for ! vect_hw_misalign.=