From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 65D623857C71; Fri, 18 Feb 2022 09:28:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65D623857C71 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104582] [11/12 Regression] Unoptimal code for __negdi2 (and others) from libgcc2 due to unwanted vectorization Date: Fri, 18 Feb 2022 09:28:30 +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: 12.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.3 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 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: Fri, 18 Feb 2022 09:28:30 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104582 --- Comment #12 from rguenther at suse dot de --- On Fri, 18 Feb 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104582 >=20 > --- Comment #11 from Jakub Jelinek --- > True. > So another option is to try to undo some of those short vectorization cas= es > during isel, expansion or later, though e.g. for the negdi2 case it will = go > already during expansion into memory. Yes, there are duplicates about this issue and it's really hard to solve generally. There's the possibility to try improving on the costing side but currently the cost hooks just see ix86_vector_costs::add_stmt_cost (this=3D0x41b88c0, count=3D1,=20 kind=3Dvec_construct, stmt_info=3D0x0, vectype=3D,=20 misalign=3D0, where=3Dvect_prologue) so they have no idea about the feeding stmts. The cost entry is generated by vect_prologue_cost_for_slp which knows the scalar operands but we do not pass the SLP node down to the cost hooks (that's something on my list but my idea was to push it back when we only have SLP nodes and thus could go w/o the stmt_info then). The other possibility is (for the original testcase) to anticipate that RTL expansion will expand 'w' to a TImode register and take that as a reason to pessimize vectorization (but we don't know how it's going to be used, so that's probably a flawed attempt). The only short-term fixes are a) biasing the costing, regressing the from memory case, b) pass down the SLP node where available and look at the defs of the CTOR components, costing a gpr->xmm move where it can be anticipated. b) is more future-proof, if we'd take that at this point I can see how intrusive it would be.=