From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 1CF403857BBD; Fri, 15 Jul 2022 08:10:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CF403857BBD Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B296534059; Fri, 15 Jul 2022 08:10:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1657872645; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vtbLn3VmN+LoxzLV16F8yFHKl04Pu1wiVUgUOZpfZaI=; b=dnKSXWaAWhZV0dg2Omv+5gtXGs1bxom//6ACNWtwyt0J8A7yvsAcUaWjrFdk83XTO3qZzN JBRdkC0lxsvCCOKt9EFQP9Ts1jSI1y20aemmvNEUPRfcHIwFxCHMD3sE9SOYoN1pagUvx3 RGZRQg71ZKTxcT3F5qWxu7J2by57xEs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1657872645; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vtbLn3VmN+LoxzLV16F8yFHKl04Pu1wiVUgUOZpfZaI=; b=FnAMRF4bwwXueoRp+TOrqdq0OHBD1MrAOcNgQmajQEQD2/ZYcouQFxTppg//c4UdNw8TeS A2u8mx/x6o9N8/Bw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 92A6013AC3; Fri, 15 Jul 2022 08:10:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id AmKEIgUh0WJcHQAAMHmgww (envelope-from ); Fri, 15 Jul 2022 08:10:45 +0000 Message-ID: <0d025b0a-0094-6457-0073-2bd7ccf51c80@suse.cz> Date: Fri, 15 Jul 2022 10:10:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: Creating a wrapper around a function at compile time Content-Language: en-US To: Erick Ochoa Cc: Richard Biener , GCC Development References: <90b22551-734c-72e4-ad33-864385162f9f@suse.cz> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=no 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, 15 Jul 2022 08:10:50 -0000 On 7/14/22 16:25, Erick Ochoa wrote: > > > On Thu, 14 Jul 2022 at 16:10, Martin Liška > wrote: > > On 7/14/22 16:08, Erick Ochoa via Gcc wrote: > > Last time I checked, value profiling can only track a single value per > > statement. > > Hi. > > Take a look at HIST_TYPE_INDIR_CALL which we use for tracking at maximum 32 > (#define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32) and we use for indirect call > speculative calls which you can see for instance here: > > ./gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C > > > Thanks Martin, > > I'll give it a read. However, I have mis-spoken. If my understanding is correct: multiple values are tracked, but only the values of a single variable/expression per statement are tracked. That means that for a gcall (which is a single statement and) which has n argument expressions, I believe that the naive way to track all argument expressions is not possible without extending how histograms are associated to statements. Perhaps canonicalizing how callsites work (i.e., only variables are allowed as arguments in call sites and then associating a histogram to the definition of the variables being used in call sites) would be enough, but I haven't given it much thought for the consequences that might follow from this. Yes, you are correct that we track only one type of histogram per each gimple statement: histogram_value gimple_histogram_value_of_type (struct function *fun, gimple *stmt, enum hist_type type) { histogram_value hist; for (hist = gimple_histogram_value (fun, stmt); hist; hist = hist->hvalue.next) if (hist->type == type) return hist; return NULL; } but that could be theoretically relaxed for your use-case. Cheers, Martin >   > > > Cheers, > Martin >