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 803503856DD9; Fri, 1 Jul 2022 12:48:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 803503856DD9 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 4B3F8220FE; Fri, 1 Jul 2022 12:48:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1656679710; 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=GM0IyaqnQBZABz62iKThKE/4DVQZ2CpEWOvA8BqH4W8=; b=YuSTQl4lcUsXhxv6zAEo7e3ftOmlpXc9sL7zC0KoCGcZhBxfpj0e+u3TVfFsAdJj5mL+oV bONQyjXpveMw9FNyRJTrCSIugqgBjUwkrxPghTA1ikDkiKRH9wJZvreGJGDPbPuZx/rPTP fTckwvjRu2urqrpvTIFRKP2VWqlbDZ0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1656679710; 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=GM0IyaqnQBZABz62iKThKE/4DVQZ2CpEWOvA8BqH4W8=; b=5c0DYoi/4BJU/fbJ5n3U8lIDywBeO5BneVTHNSa6NfLE6vYsaeCTDNSTqlo8YEs+koZLFK gnc1Rraf+my1Z5Cg== 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 248BD2C141; Fri, 1 Jul 2022 12:48:30 +0000 (UTC) From: Martin Jambor To: Erick Ochoa , gcc@gcc.gnu.org Subject: Re: Question about speculative make_edge_direct_to_target during LTO/IPA_PASS In-Reply-To: References: User-Agent: Notmuch/0.35 (https://notmuchmail.org) Emacs/28.1 (x86_64-suse-linux-gnu) Date: Fri, 01 Jul 2022 14:48:27 +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, 01 Jul 2022 12:48:35 -0000 Hi, On Fri, Jul 01 2022, Erick Ochoa via Gcc wrote: > Hi, > > I have a pass that is able to speculate the target of indirect function > calls. This pass is an IPA_PASS. It: > > 1. generates summaries with the possible targets. > 2. writes analysis summary > 3. reads analysis summary > 4. combines the results from multiple partitions and if needed fixes the > targets > 5. writes opt summary > 6. reads opt summary > 7. calls ipa_make_edge_direct_to_target with speculative=true Why so late, why not as part of number 4? > > This pass is successful in that I can observe the transformation in the > generated gimple. (A function test and a direct function call in one branch > and the indirect function call in the other.) However, I would like to > make the edges in the call graph visible to other IPA passes, particularly > ipa-cp. As long as you schedule your pass before IPA-CP and create speculative edges before its WPA, that should then just work. I mean, IPA-CP may be too conservative and its heuristics may need to be tweaked, but it should see the speculative edges and propagate through them just fine. Is that not so? > For this, I would need to create virtual clones during the WPA > stage. I do not understand what the virtual clones would represent. How should they be different from the original when materialized? > I am a little unfamiliar with virtual clones. What kind of > information would I need to store in the analysis summary and is there a > way to create speculative virtual clones? Can someone point to a similar > piece of code in GCC where this happens? Well, IPA-CP creates virtual clones. Information associated with it represents the special context for which they are created (see create_specialized_node in ipa-cp.cc) but I am not sure what that would be in your case. I am also not sure what you mean by speculative virtual clones, if virtual clones with only speculative edges leading to them, than those can exist and (unless the call is considered cold), they are not removed as uninteresting (see code in speculation_useful_p). But I really think that making the edges speculative early is likely to fix your issues. Martin