From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48110 invoked by alias); 26 Sep 2018 17:12:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 48096 invoked by uid 89); 26 Sep 2018 17:12:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=in_lto_p, H*c:alternative X-HELO: aserp2120.oracle.com Received: from aserp2120.oracle.com (HELO aserp2120.oracle.com) (141.146.126.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Sep 2018 17:12:05 +0000 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8QH40RO060979; Wed, 26 Sep 2018 17:12:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=8l+dgi10qxue19r2tVMFkETzqD9fMSXufZZCi7fQW40=; b=gK5bj34tT0q0z42+PQ+ARJ8DX7lIYdyN81uwlL56KQ21RkhGsXD61FGopb7A/ZxNMqj6 TsJCiLQiGGAV5w40dFwKCqyLW6snSBeEw6G9EhggnnMe4xkQPcKv4ymkXmHZbgrDlUMr G1pg7Ve4lZOKf3sNI1t1OaS/q6YculvIpqJXSUTH7A9QrCGLAcr7co+Wg3JMwp85qECx Ryxg/5wVfYraZOEWVA+2kBvDJZEQAOyKwBzBrWlRaXmnzikQbEmviP76BymgII3DCEJ6 NMMzZzZvsVfeg5ECZYiNhM9ybduJJJdMHwZJa1W1w6F72YEKveLBDMbIcCF5ulJ9AR2v ZA== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2mndppm06s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Sep 2018 17:12:03 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w8QHC2xG007691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Sep 2018 17:12:02 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8QHC1Hq007386; Wed, 26 Sep 2018 17:12:01 GMT Received: from dhcp-10-159-229-214.vpn.oracle.com (/10.159.229.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Sep 2018 10:12:00 -0700 From: Qing Zhao Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions Date: Wed, 26 Sep 2018 17:12:00 -0000 In-Reply-To: <20180926150649.GD61973@kam.mff.cuni.cz> Cc: Jason Merrill , Jeff Law , Richard Biener , gcc Patches , Jakub Jelinek , Alexander Monakov , andrew Pinski , martin Sebor To: Jan Hubicka References: <7f314cc6-8cd3-a6f2-27b1-df4ef637542e@gmail.com> <5263e463-96d1-7fc5-ddff-26efa82df25f@redhat.com> <20180926150649.GD61973@kam.mff.cuni.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg01589.txt.bz2 > On Sep 26, 2018, at 10:06 AM, Jan Hubicka wrote: >=20 >> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law wrote: >>> On 9/26/18 7:38 AM, Jason Merrill wrote: >>>> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener wr= ote: >>>>> IIRC he explicitely wanted 'static' not 'hidden' linkage. Not sure >>>>> what 'internal' would mean in this context. >>>>=20 >>>> I mean internal linkage as in the C and C++ standards. >>=20 >>> Since this is primarily for kernel hot patching, I think we're looking >>> to restrict inlining to functions that have visibility limited to a >>> compilation unit. >>=20 >> Right, which is internal linkage. >>=20 >> C11: "Within one translation unit, each declaration of an identifier >> with internal linkage denotes the same object or function." >> C++17: "When a name has internal linkage, the entity it denotes can be >> referred to by names from other scopes in the same translation unit." >>=20 >> Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as >> richi suggested. >=20 > I am not quite sure if we can relate visibility flags we have at this sta= ge > to visibility in source languge in very coherent way. They change a lot = with > LTO and we may want to make this option incompatible with LTO, but even w= /o > we can turn function static that previously wasn=E2=80=99t. Looks like both LTO and whole_program need to be made incompatible with -fi= nline-only-static.=20 from my study of the function =E2=80=9Ccgraph_externally_visible_p=E2=80=9D= , comdat functions can ONLY be turned into static when either =E2=80=9Cin_lto_p=E2=80=9D or =E2=80=9Cwhole_program=E2= =80=9D is true.=20 > For example comdat that was cloned by IPA-SRA. See can_be_local_p and > comdat_can_be_unshared_p predicates. Similar problem happens to clones c= reated > by ipa-cp. >=20 > I guess we want to disable localization and cloning in this case as well. > I wonder what else. Yes, I think we should make -finline-only-static incompatible with cloning = and tree-sra too. Qing >=20 > Honza