From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by sourceware.org (Postfix) with ESMTPS id 332013858D37 for ; Wed, 20 Jul 2022 08:51:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 332013858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.215.161.154]) by smtp.orange.fr with ESMTPA id E5QGoNTBm9xlAE5QMo3uhq; Wed, 20 Jul 2022 10:51:18 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Wed, 20 Jul 2022 10:51:18 +0200 X-ME-IP: 86.215.161.154 Message-ID: Date: Wed, 20 Jul 2022 10:51:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [COMMITTED] [PATCH 1/2] Remove recursion from range_from_dom. Content-Language: en-US To: Andrew MacLeod , gcc-patches References: From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 20 Jul 2022 08:51:22 -0000 Hello, I spotted a few nits. See below. Le 20/07/2022 à 00:10, Andrew MacLeod via Gcc-patches a écrit : > diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc > index da7b8055d42..20dd5ead3bc 100644 > --- a/gcc/gimple-range-cache.cc > +++ b/gcc/gimple-range-cache.cc > @@ -1312,6 +1312,38 @@ ranger_cache::fill_block_cache (tree name, basic_block bb, basic_block def_bb) > fprintf (dump_file, " Propagation update done.\n"); > } > > +// Resolve the range of BB if the dominators range is R by calculating incoming > +// edges to this block. All lead back to the dominator so should be cheap. > +// The range for BB is set and returned in R. > + > +void > +ranger_cache::resolve_dom (vrange &r, tree name, basic_block bb) > +{ > + basic_block def_bb = gimple_bb (SSA_NAME_DEF_STMT (name)); > + basic_block dom_bb = get_immediate_dominator (CDI_DOMINATORS, bb); > + > + // if it doesn't already have a value, store the incoming range. > + if (!m_on_entry.bb_range_p (name, dom_bb) && def_bb != dom_bb) > + { > + // If the range can't be store, don't try to accumulate > + // the range in PREV_BB due to excessive recalculations. As a consequence of the refactoring, PREV_BB doesn’t exist anymore. It should be BB, I think. > + if (!m_on_entry.set_bb_range (name, dom_bb, r)) > + return; > + } > + // With the dominator set, we should be able to cheaply query > + // each incoming edge now and accumulate the results. > + r.set_undefined (); > + edge e; > + edge_iterator ei; > + Value_Range er (TREE_TYPE (name)); > + FOR_EACH_EDGE (e, ei, bb->preds) > + { > + edge_range (er, e, name, RFD_READ_ONLY); > + r.union_ (er); > + } > + // Set the cache in PREV_BB so it is not calculated again. Same here. > + m_on_entry.set_bb_range (name, bb, r); > +} > > // Get the range of NAME from dominators of BB and return it in R. Search the > // dominator tree based on MODE. (...) > @@ -1403,14 +1402,25 @@ ranger_cache::range_from_dom (vrange &r, tree name, basic_block start_bb, > fprintf (dump_file, " at function top\n"); > } > > - // Now process any outgoing edges that we seen along the way. > + // Now process any blocks wit incoming edges that nay have adjustemnts. > while (m_workback.length () > start_limit) > { > int_range_max er; > prev_bb = m_workback.pop (); > + if (!single_pred_p (prev_bb)) > + { > + // Non single pred means we need to cache a vsalue in the dominator ... cache a *value* in ... > + // so we can cheaply calculate incoming edges to this block, and > + // then store the resulting value. If processing mode is not > + // RFD_FILL, then the cache cant be stored to, so don't try. > + // Otherwise this becomes a quadratic timed calculation. > + if (mode == RFD_FILL) > + resolve_dom (r, name, prev_bb); > + continue; > + } > + > edge e = single_pred_edge (prev_bb); > bb = e->src; > - > if (m_gori.outgoing_edge_range_p (er, e, name, *this)) > { > r.intersect (er);