From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80976 invoked by alias); 22 Oct 2018 10:16:43 -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 80960 invoked by uid 89); 22 Oct 2018 10:16:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=extremely, arrived, skilled, Was X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Oct 2018 10:16:41 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3A245AE3E; Mon, 22 Oct 2018 10:16:39 +0000 (UTC) Subject: Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions) From: =?UTF-8?Q?Martin_Li=c5=a1ka?= To: Jan Hubicka Cc: Qing Zhao , Martin Jambor , live-patching@vger.kernel.org, gcc Patches References: <20180927085829.GJ61973@kam.mff.cuni.cz> <817E4C4A-F81B-4E09-9645-04E38A1B9E74@oracle.com> <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> Message-ID: <90c91045-cb9d-0bd2-fad3-d16426ceede6@suse.cz> Date: Mon, 22 Oct 2018 10:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <54a75932-201b-671c-0a63-d1a5d8d7b562@suse.cz> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg01311.txt.bz2 @honza: PING On 10/3/18 12:53 PM, Martin Li¹ka wrote: > On 10/3/18 11:04 AM, Jan Hubicka wrote: >>> >>> That was promised to be done by Honza Hubièka. He's very skilled in IPA optimizations and he's aware >>> of optimizations that cause troubles for live-patching. >> >> :) I am not sure how skilful I am, but here is what I arrived to. > > Heh! Thanks for the analysis. > >> >> We have transformations that are modeled as clonning, which are >> - inlining (can't be disabled completely because of always inline, but -fno-inline >> does most of stuff) >> - cloning (disabled via -fno-ipa-cp) >> - ipa-sra (-fno-ipa-sra) >> - splitting (-fno-partial-inlining) >> These should play well with Martin's tracking code > > I hope so! > >> >> We propagate info about side effects of function: >> - function attribute discovery (pure, const, nothrow, malloc) >> Some of this can be disabled by -fno-ipa-pure-const, but not all >> of it. > > Would it be possible to add option for the remaining ones? > > Nothrow does not have flag but it is obviously not a concern >> for C++ > > s/C++/C? > >> - 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) > > Would it be possible to add flag for it? Can you please point to a location where > the optimization happen? > >> - inter-procedural register allocation (-fno-ipa-ra) >> >> We perform discovery of functions/variables with no address taken and >> optimizations that are not valid otherwise such as duplicating them >> or doing skipping them for alias analysis (no flag to disable) > > Can you be please more verbose here? What optimizations do you mean? > >> >> Identical code folding merges function bodies that are semanticaly equivalent >> and thus one can't patch one without patching another, -fno-ipa-icf > > Agree, I recommend disabling that. > >> >> Unreachable code/variable removal may be concern too (no flag to disable) > > For functions that should be fine and handled by my script. > For variables can be problem when a variable becomes alive But that > should be extremely rare for live-patching. > >> >> Write only global variable discovery (no flag to dosable) > > Similarly. > >> >> Visibility changes with -flto and/or -fwhole-program >> >> We also have profile propagation (discovery of cuntions used only in cold regions, >> but that I guess is only performance issue not correctness) >> No flag to disable > > Hope these 2 does not happen for current Linux kernel. > > Martin > >> >> Honza >> >>> >>> Martin >>> >>>> >>>> thanks. >>>> >>>> Qing >>>> >>> >