From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ED2703871018; Tue, 17 Aug 2021 09:29:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED2703871018 From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/101944] suboptimal SLP for reduced case from namd_r Date: Tue, 17 Aug 2021 09:29:49 +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: X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: 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, 17 Aug 2021 09:29:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101944 --- Comment #1 from Kewen Lin --- The original costing shows the vectorized version wins, by checking the costings, it missed to model the cost of lane extraction, the patch was posted in: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577422.html With the proposed adjustment above, the costings become to: reduc.c:24:34: note: Cost model analysis for part in loop 0: Vector cost: 17 Scalar cost: 17 Now we consider vectorization is still profitable when both cost are equal, so the SLP still performs. One thing can make it different is that: when we do costing, math optimization doesn't happen, there are no FMA-style operations, but finally some multiply and subtraction is optimized to FMS. If costing for scalar faces two multiply-and-sub (counted as 2) instead of two multiplies and subtractions (counted as 4), vs. vector costing 1 instead of 2. It ends up with scalar 15 vs. vector 16. But it seems not practical since we can't predict the later processing well, I tried to hack pass_optimize_widening_mul to run before slp, I saw it failed earlier.=