From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90759 invoked by alias); 5 Nov 2018 22:26:51 -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 90747 invoked by uid 89); 5 Nov 2018 22:26:50 -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,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=H*c:MHil, H*c:HpplH, expand_call, 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; Mon, 05 Nov 2018 22:26:48 +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 wA5MOhsJ194187; Mon, 5 Nov 2018 22:26:46 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=QSNoWxFssrPbgzoqbyv7pzrmWB3s3WFwgWtz+tNFLdo=; b=AcaDmPQ3QsU/GokKu740O3mcvZtw8CpA2IanArSgUuoq9bV38m7d9meuADYaezGakSOU EW3xtzJSO/yL289TcFbife0+SJ0t23WgNZkPLwqHbsbg+LipaSzws3RoVq+J4eNxnnfw AJu5jGPjYH/MkTiXkAhm8hM0UoNyvjQyc1cCnYQhRnvn+H2iWgLjrPbt1WzLjEFBDSAG NHVN8JJpY5pOW72cC11KeT3wdfE/bSli16zZ/F5m2kTDtZdByQoxuXwV45VyvvXmmBOC OHLQhHc0+x1tysxDUQfCfiNOBEfy9uWVZIEQHnDesnC4h63JeKEVaHL+ZFlD0uUMLNte 1Q== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2nh3mphwcn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Nov 2018 22:26:46 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA5MQjnN030719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 5 Nov 2018 22:26:45 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA5MQi9Y024316; Mon, 5 Nov 2018 22:26:45 GMT Received: from dhcp-10-159-144-166.vpn.oracle.com (/10.159.144.166) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Nov 2018 14:26:44 -0800 From: Qing Zhao Message-Id: <835ABE68-CDCE-4DD4-93DA-489EF6E6EB39@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions) Date: Mon, 05 Nov 2018 22:26:00 -0000 In-Reply-To: <20181105095135.j3mnzox6rkktkoto@kam.mff.cuni.cz> Cc: =?utf-8?Q?Martin_Li=C5=A1ka?= , Martin Jambor , live-patching@vger.kernel.org, gcc Patches To: Jan Hubicka References: <5CB6BDBE-3F49-4BFE-AF10-5E8181C49181@oracle.com> <1a023bdc-28a6-eb41-b449-4d096f12064f@suse.cz> <048D9997-B7AF-444A-BF7E-79944DE8F174@oracle.com> <3E37D3A8-2D19-41C2-BA8A-8F0EFA1B4D5C@oracle.com> <10a54034-279b-a406-8466-55558effbf24@suse.cz> <20181003090457.GJ57692@kam.mff.cuni.cz> <54a75932-201b-671c-0a63-d1a5d8d7b562@suse.cz> <90c91045-cb9d-0bd2-fad3-d16426ceede6@suse.cz> <20181105095135.j3mnzox6rkktkoto@kam.mff.cuni.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00317.txt.bz2 >>>=20 >>>> - ipa-pta (disabled by default, -fno-ipa-pta) >>>> - ipa-reference (list of accessed/modified global vars), disable by -= fno-ipa-refernece >>>> - stack alignment requirements (no flag to disable) >>>=20 >>> Would it be possible to add flag for it? Can you please point to a loca= tion where >>> the optimization happen? >=20 > In expand_call >=20 > /* Figure out the amount to which the stack should be aligned. */ > preferred_stack_boundary =3D PREFERRED_STACK_BOUNDARY; > if (fndecl) > { > struct cgraph_rtl_info *i =3D cgraph_node::rtl_info (fndecl); > /* Without automatic stack alignment, we can't increase preferred > stack boundary. With automatic stack alignment, it is > unnecessary since unless we can guarantee that all callers will > align the outgoing stack properly, callee has to align its > stack anyway. */ > if (i > && i->preferred_incoming_stack_boundary > && i->preferred_incoming_stack_boundary < preferred_stack_bounda= ry) > preferred_stack_boundary =3D i->preferred_incoming_stack_boundary; > } >=20 As I checked, in the above, i->preferred_incoming_stack_boundary is set to = non-zero when "decl_binds_to_current_def_p ()=E2=80=9D is TRUE as the following: (in= rest_of_clean_state() of final.c) /* We can reduce stack alignment on call site only when we are sure that the function body just produced will be actually used in the final executable. */ if (decl_binds_to_current_def_p (current_function_decl)) { unsigned int pref =3D crtl->preferred_stack_boundary; if (crtl->stack_alignment_needed > crtl->preferred_stack_boundary) pref =3D crtl->stack_alignment_needed; cgraph_node::rtl_info (current_function_decl) ->preferred_incoming_stack_boundary =3D pref; } It looks like that =E2=80=9Cdecl_binds_to_current_def_p()=E2=80=9D will be= FALSE when the routine is live-patched, right?=20 So, should we disable all the places that guided by =E2=80=9Cdecl_binds_to_= current_def_p()=E2=80=9D?=20 thanks. Qing