From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 579BC386EC30 for ; Thu, 24 Sep 2020 10:54:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 579BC386EC30 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 3BB6428299D; Thu, 24 Sep 2020 12:54:42 +0200 (CEST) Date: Thu, 24 Sep 2020 12:54:42 +0200 From: Jan Hubicka To: Richard Biener Cc: GCC Patches , d@dcepelik.cz Subject: Re: Add access through parameter derference tracking to modref Message-ID: <20200924105442.GA34649@kam.mff.cuni.cz> References: <20200924090555.GG6758@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 24 Sep 2020 10:54:45 -0000 > > + else if (TREE_CODE (op) == SSA_NAME > > + && POINTER_TYPE_P (TREE_TYPE (op))) > > + { > > + if (DECL_P (base) && !ptr_deref_may_alias_decl_p (op, base)) > > + return false; > > + if (TREE_CODE (base) == SSA_NAME > > + && !ptr_derefs_may_alias_p (op, base)) > > + return false; > > + } > > this all looks redundant - why is it important to look at the > base of ref, why not simply ask below (*) > > > + modref_access_node *access_node; > > + FOR_EACH_VEC_SAFE_ELT (ref_node->accesses, k, access_node) > > + { > > + if (num_tests >= max_tests) > > + return true; > > + > > + if (access_node->parm_index == -1 > > + || (unsigned)access_node->parm_index > > + >= gimple_call_num_args (stmt)) > > + return true; > > + > > + tree op = gimple_call_arg (stmt, access_node->parm_index); > > + > > + alias_stats.modref_baseptr_tests++; > > + > > + /* Lookup base, if this is the first time we compare bases. */ > > + if (!base) > > Meh, so this function is a bit confusing with base_node, ref_node, > access_node and now 'base' and 'op'. The loop now got a > new nest as well. > > I'm looking for a high-level description of the modref_tree <> > but cannot find any which makes reviewing this quite difficult... There is a description in ipa-modref.c though it may need a bit of expanding. Basically the modref summary represents a decision tree for tree-ssa-alias that has three levels 1) base which records base alias set, 2) ref which records ref alias set and 3) access wich presently records info whether the access is a dreference of pointer passed by parameter. In future I will re-add info about offset/size and base type. It would be posisble to record the access path though I am not sure if that it is worth the effort > > > + { > > + base = ref->ref; > > + while (handled_component_p (base)) > > + base = TREE_OPERAND (base, 0); > > ao_ref_base (ref)? OK, that might strip an inner > MEM_REF, yielding in a decl, but ... > > > + if (TREE_CODE (base) == MEM_REF > > + || TREE_CODE (base) == TARGET_MEM_REF) > > + base = TREE_OPERAND (base, 0); > > that might happen here, too. But in the MEM_REF case base > is a pointer. > > > + } > > + > > + if (base_may_alias_with_dereference_p (base, op)) > > So this is a query purely at the caller side - whether 'ref' may > alias 'op'. > > --- > > (*) ptr_deref_may_alias_ref_p_1 (op, ref) > > without any of the magic? Hmm, it may actually just work, I did not know that looks through memrefs, let me re-test the patch. > > Can you please amend ipa-modref-tree.h/c with a toplevel comment > layint out the data structure and what is recorded? I will do (but need to think bit of a redundancy between comment in ipa-modref and ipa-modref-tree) Honza > > Thanks, > Richard. > > > + return true; > > + num_tests++; > > + } > > } > > } > > return false; > > @@ -2510,7 +2584,7 @@ ref_maybe_used_by_call_p_1 (gcall *call, ao_ref *ref, bool tbaa_p) > > modref_summary *summary = get_modref_function_summary (node); > > if (summary) > > { > > - if (!modref_may_conflict (summary->loads, ref, tbaa_p)) > > + if (!modref_may_conflict (call, summary->loads, ref, tbaa_p)) > > { > > alias_stats.modref_use_no_alias++; > > if (dump_file && (dump_flags & TDF_DETAILS)) > > @@ -2934,7 +3008,7 @@ call_may_clobber_ref_p_1 (gcall *call, ao_ref *ref, bool tbaa_p) > > modref_summary *summary = get_modref_function_summary (node); > > if (summary) > > { > > - if (!modref_may_conflict (summary->stores, ref, tbaa_p)) > > + if (!modref_may_conflict (call, summary->stores, ref, tbaa_p)) > > { > > alias_stats.modref_clobber_no_alias++; > > if (dump_file && (dump_flags & TDF_DETAILS))