From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 07D16383DB82; Tue, 21 Jun 2022 08:20:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 07D16383DB82 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely Date: Tue, 21 Jun 2022 08:20:27 +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: 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords cf_reconfirmed_on bug_status everconfirmed cc blocked cf_gcctarget 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: Tue, 21 Jun 2022 08:20:28 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106038 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization Last reconfirmed| |2022-06-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |rguenth at gcc dot gnu.org Blocks| |53947 Target| |x86_64-*-* --- Comment #4 from Richard Biener --- The vectorizer does not anticipate store-merging performing "vectorization"= in GPRs and thus the scalar cost is off (it also doesn't anticipate the differ= ent ISA constraints wrt xmm vs gpr usage). I wonder if we should try to follow what store-merging would do with respect to "vector types", thus prefer "general vectors" (but explicitely via integ= er types since we can't have vector types with both integer and vector modes) when possible (for bit operations and plain copies). scanning over an SLP instance (group) and substituting integer types for SLP_TREE_VECTYPE might be possible. Doing this nicely somewhere is going to be more interesting. Far away vectorizable_* should compute a set of { vector-type, cost } pairs from the set of input operand vector-type[, cos= t] pair sets. Not having "generic" vectors as vector types and relying on vector lowering to expand them would be an incremental support step for this I guess. "backwards STV" could of course also work on the target side. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations=