From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C183438185E6; Mon, 1 Jul 2024 10:10:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C183438185E6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1719828644; bh=WAAACkIR7DgWI8D47Tb4jsS4GwS1sC/qTK8YzZXFuyw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=U4RnHnb7fPFbec97vx53kFR2Kbyuh9xgWl+TrPcLhjuV/hXXkDJM2ikck/6VlKZcg mB03Hh0SZBsi7Ru8XnD/aoJSnc5foBBV7HXjTHDJSttHkWifzgPgATvREV7HwWESDh 86gY0CER2wWveMWZV4+hO7xlzMyBIO0bT7d808Nk= From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/115629] Inefficient if-convert of masked conditionals Date: Mon, 01 Jul 2024 10:10:43 +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: 15.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: tnfchris 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: 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=3D115629 --- Comment #4 from Tamar Christina --- (In reply to Richard Biener from comment #3) > So we now tail-merge the two b[i] loading blocks. Can you check SVE > code-gen with this? If that fixes the PR consider adding a SVE testcase. Thanks, the codegen is much better now, but shows some other missing mask tracking in the vectorizer. Atm we generate: .L3: ld1w z31.s, p6/z, [x0, x6, lsl 2] <-- load a cmpeq p7.s, p6/z, z31.s, #0 <-- a =3D=3D 0, !a ld1w z0.s, p7/z, [x2, x6, lsl 2] <-- load c conditionally on !a cmpeq p7.s, p7/z, z0.s, #0 <-- !a && !c orr z0.d, z31.d, z0.d <-- a || c ld1w z29.s, p7/z, [x3, x6, lsl 2] <--- load d where !a && !c cmpne p5.s, p6/z, z0.s, #0 <--- (a || c) & loop_mask and p7.b, p6/z, p7.b, p7.b <--- ((!a && !c) && (!a && !c)= ) & loop_mask=20 ld1w z30.s, p5/z, [x1, x6, lsl 2] <-- load b conditionally on (a= || c) sel z30.s, p7, z29.s, z30.s <-- select (!a && !c, d, b) st1w z30.s, p6, [x4, x6, lsl 2] add x6, x6, x7 whilelo p6.s, w6, w5 b.any .L3 which corresponds to: # loop_mask_63 =3D PHI vect__4.10_64 =3D .MASK_LOAD (vectp_a.8_53, 32B, loop_mask_63); mask__31.11_66 =3D vect__4.10_64 !=3D { 0, ... }; mask__56.12_67 =3D ~mask__31.11_66; vec_mask_and_70 =3D mask__56.12_67 & loop_mask_63; vect__7.15_71 =3D .MASK_LOAD (vectp_c.13_68, 32B, vec_mask_and_70); mask__22.16_73 =3D vect__7.15_71 =3D=3D { 0, ... }; mask__34.17_75 =3D vec_mask_and_70 & mask__22.16_73; vect_iftmp.20_78 =3D .MASK_LOAD (vectp_d.18_76, 32B, mask__34.17_75); vect__61.21_79 =3D vect__4.10_64 | vect__7.15_71; mask__35.22_81 =3D vect__61.21_79 !=3D { 0, ... }; vec_mask_and_84 =3D mask__35.22_81 & loop_mask_63; vect_iftmp.25_85 =3D .MASK_LOAD (vectp_b.23_82, 32B, vec_mask_and_84); _86 =3D mask__34.17_75 & loop_mask_63; vect_iftmp.26_87 =3D VEC_COND_EXPR <_86, vect_iftmp.20_78, vect_iftmp.25_= 85>; .MASK_STORE (vectp_res.27_88, 32B, loop_mask_63, vect_iftmp.26_87); it looks like what's missing is that the mask tracking doesn't know that ot= her masked operations naturally perform an AND when combined. We do some of th= is in the backend but I feel like it may be better to do it in the vectorizer. In this case, the second load is conditional on the first load mask, which means it's already done an AND. And crucially inverting it means you also inverted both conditions. So there are some superflous masking operations happening. But I guess tha= t's a separate bug. Shall I just add some tests here and close it and open a n= ew PR?=