From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 352A2382CCA4; Fri, 20 May 2022 22:13:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 352A2382CCA4 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 49E7421B61; Fri, 20 May 2022 22:13:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1653084797; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aqMwu/JUhyWVeWtUa6kF2itb6uDByr86OveUSKKdvhE=; b=vYdTl6ONQO22gdiiFeYTzsUBp7OBgiJeU3EL4QTh2+O7K23CrEUcz5P+YHA4UE+d0ncpPF voQfKjA2go1dtU+Mv3CsSvpA+AVKnxdnwz+RPsygVGNZ1mCHT8I1AK8EbJVcZKct8x3W5l pEQR39CIoGmPQ9Uzkct/gfC3weL3dEY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1653084797; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aqMwu/JUhyWVeWtUa6kF2itb6uDByr86OveUSKKdvhE=; b=iUCixbtRVKBN0DFKW/iXMG9EyV9UWn8FauSttV6job44CXP5PUFoDAH3zKopW/kxz/+f3d bMUpu5iW7PjaW7DA== Received: from suse.cz (unknown [10.100.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 200232C141; Fri, 20 May 2022 22:13:17 +0000 (UTC) From: Martin Jambor To: Erick Ochoa , gcc@gcc.gnu.org Subject: Re: Question on cgraph_edge::call_stmt during LTO In-Reply-To: References: User-Agent: Notmuch/0.35 (https://notmuchmail.org) Emacs/28.1 (x86_64-suse-linux-gnu) Date: Sat, 21 May 2022 00:13:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2022 22:13:21 -0000 Hello, On Fri, May 20 2022, Erick Ochoa via Gcc wrote: > Hi, > > I'm working on a pass that looks into the estimated values during ipa-cp > and stores them for a later analyses/pass. I would like to store the real > arguments' estimates in a cgraph_edge::call_stmt or somewhere else that > makes similar sense. (Note, this is different from the formal parameters' > estimates which can be found in the lattice print out of ipa-cp). the statement is not the right place to store such pass-specific information, for reasons you described and more (especially simple memory use efficiency). Instead they should be placed into an "edge summary" (also sometimes called "call summary"), a structure similar to ipa_edge_args_sum (in ipa-prop.h and ipa-prop.cc). Unlike ipa_edge_args_sum, which is allocated at analysis phase, then streamed out and in in case of LTO, and used thrown away during the IPA analysis phase, your summary would need to be allocated at IPA analysis time, then streamed out in ipcp_write_transformation_summaries, streamed in in ipcp_read_transformation_summaries so that they can be used in the transformation phase. Usually a simple implementation of the duplication hook of an edge summary is enough for the data to survive cloning and inlining and the like. Martin