From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050:0:465::102]) by sourceware.org (Postfix) with ESMTPS id 9D0243858D39 for ; Mon, 13 Mar 2023 10:58:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9D0243858D39 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4PZtsz1CDjz9skD for ; Mon, 13 Mar 2023 11:57:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1678705079; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Rga5xd0VmsOvBnR2VVNd5DJLqR03z2S/sr4sL7uMRFc=; b=zltyvFs1aIABdKMwq6cs3TNCVAqe/eEiK2alhWqZGJUg3QOzwABS94YTJqO9msFW5bfqQJ XXLpe6qJAX5XQhetpCGx7rnaMHFqKC6SVTypfwQn1VP+RcCWRRzrLI1KO8EPOf2EtDcC2a kB9/Fc0DgKffCOOb4xvDrq29bX7FZittjpNsCt2JOoAwKLj5xddInd79tXiO1iX+7T+/ZO huY0Bg6Byr8DbWmfM2P1EM5Lj4RaxBc6WFr59pJhoJG26hgRPYoQw5hAxfy0eUavN4mAQe EeJm0eX2Mg42pe+2vxGkWBE+/2foeRuHY9HjseWjrLlXaR8DQQkuQezY3S3Lcw== From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: gcc@gcc.gnu.org Subject: cgraph: does node->inlined_to imply node->clones is non-empty? Date: Mon, 13 Mar 2023 11:24:53 +0100 Message-ID: <86bkkwude3.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4PZtsz1CDjz9skD X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_LOW,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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 furth= er 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 =3D NULL; update_inlined_to_pointer (node, node); } node->aux =3D 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. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZA8BtV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTrk8BAOWAalbWtkytFxrz/hbmJD7JtirSK0Rf39FM xEwyp2esAQDh0Eo70St6mxBP8+WKrGgEe40yPRtjjg70zTbGnw+9Cw== =99fE -----END PGP SIGNATURE----- --=-=-=--