This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Ping agian: [PATCH V2] Loop split upon semi-invariant condition (PR tree-optimization/89134)
- From: Feng Xue OS <fxue at os dot amperecomputing dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 12 Sep 2019 10:21:22 +0000
- Subject: Re: Ping agian: [PATCH V2] Loop split upon semi-invariant condition (PR tree-optimization/89134)
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NZYsBoSVeOXb73q/OXB/ASk841at3ag/VH5Socffb4s=; b=f901AHYdWeYgSI1gKFE27GR4gLbvFTo/c5PkbplBMUTHol0QGaLtfnG69eSLnG0bb//O1g2Br6XHPN3wl/nw8yQhT3IdX9e+QmYsd4fxBSIS755zkcYlIfh+fQTYdf/Bc7bgahtT3FJ4OHq5fYRBloXOGvECq0nfyg4rzFZr6pP4hvrMe90ts54VmI4NCqj1unh5O6g4azC2aIGq3tEiznHAqu8T5/5kQOqPB4RRN7zWNH01/irLj6xMQ1Z/EglEF7ertq1sIleptuZuqQVqD69zN00huhfPvy8hMvkh/dUDlJcJAXa3qOifmxy5HmyCi18DWAwuI0aPDF/sUl+3vg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i/BH2PYmZjx4A6LDk8yB9iNPwetk7bB1Oqiw1C5snunaUjF5xAreuwSiO6uGY0r3FuvDhKHKD3armpP8COH8lng1wQ/W0V0ALp4Bor0ZlWOrnqqi3QJ75ibkk2KDqWBitn6OZqe7JfCKFwP/OJyM4egfVY/thlUJ21CG0OSzhPtINecGUQk4SVHpFbgZwK++WyQByUSb1HGYNcvCD7mBasOqs275zbcGm/sXyWs0eFXKPCeJCtq3C8DroBiCDLL+rIGMunw5aHZ9yCV0UvPJxmZXM7C22M9XQfmlTipUldG21yukelGqm2KMJUkWEWLNsuCRi9zeCh4wwjM9gpv/Fw==
- References: <BYAPR01MB486993CD64F7326C9029BFBFF7490@BYAPR01MB4869.prod.exchangelabs.com> <CAFiYyc0+=1TDgkO0BQN_hdTBo=Nf+h_xF5SB6O8VM5s_cppQdg@mail.gmail.com> <BYAPR01MB4869641E6E9DCB49618D27B0F7300@BYAPR01MB4869.prod.exchangelabs.com>,<CAFiYyc1tYTkUkziKYY6r=k8XFe5Er=oNkxW-cerbP7oq06c=wA@mail.gmail.com>,<BYAPR01MB48697F52CD6FF3DFE2F78211F7EA0@BYAPR01MB4869.prod.exchangelabs.com> <BYAPR01MB4869403E98A1528A9219419CF7CF0@BYAPR01MB4869.prod.exchangelabs.com>,<alpine.LSU.2.21.1907291743000.25869@wotan.suse.de>
Hi, Michael,
Since I was involved in other tasks, it is a little bit late to reply you. Sorry
for that. I composed a new one with your suggestions. Please review that
when you are in convenience.
> Generally I do like the idea of the transformation, and the basic building
> blocks seem to be sound. But I dislike it being a separate pass, so
> please integrate the code you have written into the existing loop split
> pass. Most building blocks can be used as is, except the main driver.
This new transformation was integrated into the pass of original loop split.
>> +@item max-cond-loop-split-insns
>> +The maximum number of insns to be increased due to loop split on
>> +semi-invariant condition statement.
> "to be increased" --> "to be generated" (or "added")
Done.
>> +@item min-cond-loop-split-prob
>> +The minimum threshold for probability of semi-invaraint condition
>> +statement to trigger loop split.
> typo, semi-invariant
Done.
> I think somewhere in the docs your definition of semi-invariant needs
> to be stated in some form (can be short, doesn't need to reproduce the
> diagram or such), so don't just replicate the short info from the
> params.def file.
Done.
>> +DEFPARAM(PARAM_MIN_COND_LOOP_SPLIT_PROB,
>> + "min-cond-loop-split-prob",
>> + "The minimum threshold for probability of semi-invaraint condition "
>> + "statement to trigger loop split.",
> Same typo: "semi-invariant".
Done.
>> -/* This file implements loop splitting, i.e. transformation of loops like
>> +/* This file implements two kind of loop splitting.
> kind_s_, plural
Done.
>> +/* Another transformation of loops like:
>> +
>> + for (i = INIT (); CHECK (i); i = NEXT ())
>> + {
>> + if (expr (a_1, a_2, ..., a_n))
>> + a_j = ...; // change at least one a_j
>> + else
>> + S; // not change any a_j
>> + }
> You should mention that 'expr' needs to be pure, i.e. once it
> becomes false and the inputs don't change, that it remains false.
Done.
>> +static bool
>> +branch_removable_p (basic_block branch_bb)
>> +{
>> + if (single_pred_p (branch_bb))
>> + return true;
>> +
>> + edge e;
>> + edge_iterator ei;
>> +
>> + FOR_EACH_EDGE (e, ei, branch_bb->preds)
>> + {
>> + if (dominated_by_p (CDI_DOMINATORS, e->src, branch_bb))
>> + continue;
>> +
>> + if (dominated_by_p (CDI_DOMINATORS, branch_bb, e->src))
>> + continue;
> My gut feeling is surprised by this. So one of the predecessors of
> branch_bb dominates it. Why should that indicate that branch_bb
> can be safely removed?
>
> Think about something like this:
>
> esrc --> cond_bb --> branch_bb
> '-------------------^
If all predecessors of branch_bb dominate it, these predecessors should also
be in dominating relationship among them, and the conditional statement must
be branch_bb's immediate dominator, and branch_bb is removable. In your example.
For "esrc", loop is continued, nothing is impacted. But in the next iteration, we
encounter "cond_bb", it does not dominate "branch_bb", so the function return
false in the following return statement.
> (cond_bb is the callers bb of the cond statement in question). Now esrc
> dominates branch_bb but still you can't simply remove it, even if
> the cond_bb->branch_bb edge becomes unexecutable.
>> +static int
>> +get_cond_invariant_branch (struct loop *loop, gcond *cond)
> Please return an edge here, not an edge index (which removes the using of
> -1). I think the name (and comment) should consistently talk about
> semi-invariant, not invariant. For when you really need an edge index
> later, you could use "EDGE_SUCC(bb, 0) != edge". But you probably don't
> really need it, e.g. instead of using the gimple pass-local-flag on a
> statement you can just as well also store the edge in your info structure.
Done.
>> +static bool
>> +is_cond_in_hidden_loop (const struct loop *loop, basic_block cond_bb,
>> + int branch)
> With above change in get_cond_invariant_branch, this also should
> take an edge, not a bb+edge-index.
Done.
>> +static int
>> +compute_added_num_insns (struct loop *loop, const_basic_block cond_bb,
>> + int branch)
> This should take an edge as well.
Done.
>> + for (unsigned i = 0; i < loop->num_nodes; i++)
>> + {
>> + /* Do no count basic blocks only in opposite branch. */
>> + if (dominated_by_p (CDI_DOMINATORS, bbs[i], targ_bb_var))
>> + continue;
>> +
>> + for (gimple_stmt_iterator gsi = gsi_start_bb (bbs[i]); !gsi_end_p (gsi);
>> + gsi_next (&gsi))
>> + num += estimate_num_insns (gsi_stmt (gsi), &eni_size_weights);
> Replace the loop by
> estimate_num_insn_seq (bb_seq (bbs[i]), &eni_size_weights);
Done.
>> + /* Add a threshold for increased code size to disable loop split. */
>> + if (compute_added_num_insns (loop, cond_bb, branch) >
>> + PARAM_VALUE (PARAM_MAX_COND_LOOP_SPLIT_INSNS))
> Operator should be first on next line, not last on previous line.
Done.
>> + /* Skip conditional statement that is inside a nested unrecognized loop. */
>> + if (is_cond_in_hidden_loop (loop, cond_bb, branch))
>> + return false;
> This part (as well as is_cond_in_hidden_loop implementation) had me
> confused for a while, because "unrecognized" loops seems strange. I think
> I now know what you try to do here, but I wonder if there's an easier way,
> or at least about which situations you stumbled into that made you write
> this code.
Use BB_IRREDUCIBLE_LOOP flag to check that, for tree-loop-init pass
requires LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS which marks
irreducible loops.
>> +
>> + /* Temporarily keep branch index in conditional statement. */
>> + gimple_set_plf (cond, GF_PLF_1, branch);
> i.e. here, store the edge in your info structure.
Done.
>> +/* Main entry point to perform loop splitting for suitable if-conditions
>> + in all loops. */
>> +
>> +static unsigned int
>> +tree_ssa_split_loops_for_cond (void)
> So, from here on the code should be integrated into the existing code
> of the file (which might need changes as well for this integration to look
> good).
Done.
Thanks,
Feng