From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73095 invoked by alias); 30 Aug 2019 08:42:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 73086 invoked by uid 89); 30 Aug 2019 08:42:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:BYAPR01 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Aug 2019 08:42:27 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id BAC41B035; Fri, 30 Aug 2019 08:42:24 +0000 (UTC) From: Martin Jambor To: Feng Xue OS , "gcc-patches\@gcc.gnu.org" , Jan Hubicka Cc: Subject: Re: [PATCH] Generalized predicate/condition for parameter reference in IPA (PR ipa/91088) In-Reply-To: References: User-Agent: Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-suse-linux-gnu) Date: Fri, 30 Aug 2019 09:00:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg02047.txt.bz2 Hi, On Fri, Aug 30 2019, Feng Xue OS wrote: >> (It's a bad idea to make ChangeLog entries part of the patch, it won't >> apply to anyone, not even to you nowadays. ) > Got it. Will not include this kind of info in later patches. > >> I understand describing these things is difficult, but flatten is >> strange way to describe what the function does. What about somthing >> like the following? >> >> Analyze EXPR if it represents a series of simple operations performed on >> a function parameter and return true if so. FBI, STMT, INDEX_P, SIZE_P >> and AGGPOS have the same meaning like in >> unmodified_parm_or_parm_agg_item. Operations on the parameter are >> recorded to PARAM_OPS_P if it is not NULL. > Operations should be recorded in some place, and this is why PARAM_OPS_P > is used. Not quite understand this point. I was merely suggesting a better comment describing the function you are introducing. > >>> + /* Find use of parameter, add a convert operation to describe >>> + result type, which may not be same as parameter type. */ >>> + eval_op.val_is_rhs = false; >>> + eval_op.val = NULL_TREE; >>> + eval_op.code = VIEW_CONVERT_EXPR; >>> + eval_op.type = TREE_TYPE (expr); >>> + >>> + vec_safe_insert (*param_ops_p, 0, eval_op); > >> If we get here in the first iteration of the loop, could we not insert >> anything into the vector and handle such cases in >> evaluate_conditions_for_known_args like we do today (well, with >> fold_convert might be better)? It could save quite some memory and it >> is important to try keep the memory footprint down in IPA summaries. > Here is a little trick to make code of folding in evaluate_conditions_for_known_args () > be simple. It does consume some memory for most cases. Will consider other way > and remove this. Thinking about it a bit more, I think you simply do not want to ever push the extra VIEW_CONVERT_EXPR to the vector and in evaluate_conditions_for_known_args always do a fold_convert to the desired type (similarly like we do today). Thanks, Martin > >> Also, I think you want a parameter to limit the maximum length of >> param_ops_p, at some point someone will come with some crazy >> machine-generated code that will create huge vectors. > Yes. Exactly. > > Thanks, > > Martin