From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 31C853857034 for ; Thu, 31 Mar 2022 12:57:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 31C853857034 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C498C23A; Thu, 31 Mar 2022 05:57:20 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 34FDF3F66F; Thu, 31 Mar 2022 05:57:20 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener , gcc-patches@gcc.gnu.org, Jakub Jelinek , richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek Subject: Re: [PATCH] tree-optimization/104912 - ensure cost model is checked first References: <20220321151031.9B0CB133B6@imap2.suse-dmz.suse.de> Date: Thu, 31 Mar 2022 13:57:18 +0100 In-Reply-To: <20220321151031.9B0CB133B6@imap2.suse-dmz.suse.de> (Richard Biener's message of "Mon, 21 Mar 2022 16:10:31 +0100 (CET)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2022 12:57:23 -0000 Richard Biener writes: > The following makes sure that when we build the versioning condition > for vectorization including the cost model check, we check for the > cost model and branch over other versioning checks. That is what > the cost modeling assumes, since the cost model check is the only > one accounted for in the scalar outside cost. Currently we emit > all checks as straight-line code combined with bitwise ops which > can result in surprising ordering of checks in the final assembly. Yeah, this had bugged me too, and meant that we made some bad decisions in some of the local benchmarks we use. Was just afraid to poke at it, since it seemed like a deliberate decision. :-) > Since loop_version accepts only a single versioning condition > the splitting is done after the fact. > > The result is a 1.5% speedup of 416.gamess on x86_64 when compiling > with -Ofast and tuning for generic or skylake. That's not enough > to recover from the slowdown when vectorizing but it now cuts off > the expensive alias versioning test. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > OK for trunk? > > For the rest of the regression my plan is to somehow factor in > the evolution of the number of iterations in the outer loop > (which is {1, +, 1}) to somehow bump the static profitability > estimate and together with the "cheap" cost model check never > execute the vectorized version (well, it is actually never executed, > but only because the alias check fails). > > Thanks, > Richard. > > 2022-03-21 Richard Biener > > PR tree-optimization/104912 > * tree-vect-loop-manip.cc (vect_loop_versioning): Split > the cost model check to a separate BB to make sure it is > checked first and not combined with other version checks. > --- > gcc/tree-vect-loop-manip.cc | 53 ++++++++++++++++++++++++++++++++++--- > 1 file changed, 50 insertions(+), 3 deletions(-) > > diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc > index a7bbc916bbc..8ef333eb31b 100644 > --- a/gcc/tree-vect-loop-manip.cc > +++ b/gcc/tree-vect-loop-manip.cc > @@ -3445,13 +3445,28 @@ vect_loop_versioning (loop_vec_info loop_vinfo, > cond_expr =3D expr; > } >=20=20 > + tree cost_name =3D NULL_TREE; > + if (cond_expr > + && !integer_truep (cond_expr) > + && (version_niter > + || version_align > + || version_alias > + || version_simd_if_cond)) > + cost_name =3D cond_expr =3D force_gimple_operand_1 (unshare_expr (co= nd_expr), > + &cond_expr_stmt_list, > + is_gimple_val, NULL_TREE); > + > if (version_niter) > vect_create_cond_for_niters_checks (loop_vinfo, &cond_expr); >=20=20 > if (cond_expr) > - cond_expr =3D force_gimple_operand_1 (unshare_expr (cond_expr), > - &cond_expr_stmt_list, > - is_gimple_condexpr, NULL_TREE); > + { > + gimple_seq tem =3D NULL; > + cond_expr =3D force_gimple_operand_1 (unshare_expr (cond_expr), > + &tem, > + is_gimple_condexpr, NULL_TREE); > + gimple_seq_add_seq (&cond_expr_stmt_list, tem); > + } >=20=20 > if (version_align) > vect_create_cond_for_align_checks (loop_vinfo, &cond_expr, > @@ -3654,6 +3669,38 @@ vect_loop_versioning (loop_vec_info loop_vinfo, > update_ssa (TODO_update_ssa); > } >=20=20 > + /* Split the cost model check off to a separate BB. Costing assumes > + this is the only thing we perform when we enter the scalar loop. */ Maybe =E2=80=9C=E2=80=A6from a failed cost decision=E2=80=9D or something? = Might sounds out of context like it applied more generally. > + if (cost_name) > + { > + gimple *def =3D SSA_NAME_DEF_STMT (cost_name); I realise it should only happen very rarely if at all, but is it absolutely guaranteed that the cost condition doesn't fold to a constant? > + /* All uses of the cost check are 'true' after the check we > + are going to insert. */ > + replace_uses_by (cost_name, boolean_true_node); > + /* And we're going to build the new single use of it. */ > + gcond *cond =3D gimple_build_cond (NE_EXPR, cost_name, boolean_fal= se_node, > + NULL_TREE, NULL_TREE); > + edge e =3D split_block (gimple_bb (def), def); > + gimple_stmt_iterator gsi =3D gsi_for_stmt (def); > + gsi_insert_after (&gsi, cond, GSI_NEW_STMT); > + edge true_e, false_e; > + extract_true_false_edges_from_block (e->dest, &true_e, &false_e); > + e->flags &=3D ~EDGE_FALLTHRU; > + e->flags |=3D EDGE_TRUE_VALUE; > + edge e2 =3D make_edge (e->src, false_e->dest, EDGE_FALSE_VALUE); > + e->probability =3D prob; > + e2->probability =3D prob.invert (); Is reusing prob the right thing to do? Wouldn't the path to the vector loop end up with a probability of PROB^2? > + set_immediate_dominator (CDI_DOMINATORS, false_e->dest, e->src); > + auto_vec adj; > + for (basic_block son =3D first_dom_son (CDI_DOMINATORS, e->dest); > + son; > + son =3D next_dom_son (CDI_DOMINATORS, son)) > + if (EDGE_COUNT (son->preds) > 1) > + adj.safe_push (son); > + for (auto son : adj) > + set_immediate_dominator (CDI_DOMINATORS, son, e->src); Seems unfortunate that so much bespoke code is needed to do an operation like this, but that's not a very constructive comment, sorry. :-) Anyway, LGTM, but I don't think I'd really be able to spot problems. Thanks, Richard > + } > + > if (version_niter) > { > /* The versioned loop could be infinite, we need to clear existing