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 ACB173858D37 for ; Tue, 14 Mar 2023 12:42:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACB173858D37 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 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 8554521A7A; Tue, 14 Mar 2023 12:42:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1678797749; 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=210a/2QPZpF7M8JHTc+51kwHi9jR6OCKb+QWaCSuBvQ=; b=YK75YprdwIvK8Zah4kDI85X4Lh3pKeobVD2VgtKekyAysyU/jWd+V19jOfBfFO8yJReUaC JPx6AfB5b+juGia4R48rcOKJtOax3VVG0fzkqpVzAYmT1IFsmdRJ57OIH+N2Th797XbBpH glwhnQYl5O4f96a/f+zsgxDztkA4AO8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1678797749; 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=210a/2QPZpF7M8JHTc+51kwHi9jR6OCKb+QWaCSuBvQ=; b=Ueku9dZzbnFVIe/9JciXzEu0UfXHtOZ/xAXogSRPzODp0RO/8QDvPU+qCr8lqwgLKJRMgL ctcu7+qL+QAesICg== 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 69C7613A1B; Tue, 14 Mar 2023 12:42:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id gcnLGLVrEGTwXgAAMHmgww (envelope-from ); Tue, 14 Mar 2023 12:42:29 +0000 Message-ID: Date: Tue, 14 Mar 2023 13:42:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: cgraph: does node->inlined_to imply node->clones is non-empty? Content-Language: en-US To: =?UTF-8?Q?Arsen_Arsenovi=c4=87?= , gcc@gcc.gnu.org References: <86bkkwude3.fsf@aarsen.me> Cc: Martin Jambor , Jan Hubicka From: =?UTF-8?Q?Martin_Li=c5=a1ka?= In-Reply-To: <86bkkwude3.fsf@aarsen.me> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi. I'm CCing my more skilled colleagues who will know the right answer. Cheers, Martin On 3/13/23 11:24, Arsen Arsenović via Gcc wrote: > Hi, > > I was debugging PR96059 and ran into a question which does not seem > obvious from the code. > > For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC > seems to try to remove an unreachable function that was already inlined > into a different unreachable function. When the original inline > happens, ipa-inline-transform.cc:clone_inlined_nodes decides not to make > a clone, since the function being cloned is a master clone but with no > non-inline clones. > > This decision later trips up the gcc_assert in: > > /* Inline clones might be kept around so their materializing allows further > cloning. If the function the clone is inlined into is removed, we need > to turn it into normal cone. */ > FOR_EACH_FUNCTION (node) > { > if (node->inlined_to > && !node->callers) > { > gcc_assert (node->clones); > node->inlined_to = NULL; > update_inlined_to_pointer (node, node); > } > node->aux = NULL; > } > > .. because it is expecting that an inlined function without callers > (which is necessarily true here as this function is unreachable and so > was ->remove ()'d earlier) has clones. > > Either removing the assertion or making clone_inline_nodes clone when > there are no existing clones 'fixes' (suppresses, but I haven't verified > whether the results are correct) the problem. > > Is this gcc_assert correct in that an inlined function without callers > necessarily must have clones? > > And as a side question, do all clone nodes have a ->clones pointing to > the same list of all clones, or are they in a tree-ish arrangement, > where clones of clones end up forming a tree, with the clone_of pointer > being a pointer to the parent? (in this instance, the node that trips > the assert has a nullptr clone_of and clones value, which would AIUI > imply that it is the original) > > This train of thinking doesn't end up involving any devirtualization > code, which the PR was originally reproduced with, but my current theory > is that devirtualizing here just exposed an edge case that is decently > well hidden, rather than it playing a crucial role. > > Thanks in advance, have a lovely day.