From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 0B85F3858CDB for ; Fri, 7 Oct 2022 14:43:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B85F3858CDB Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id BA4922804A6; Fri, 7 Oct 2022 16:43:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1665153803; h=from:from:reply-to:subject:subject: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=0Rx4OU7KhKOSYaepLxAnEP3plKtSJNdwvI1voIm04io=; b=CH4Li+QJiDpX7XIgrQu3vO/+iMD8WBCERs7AIKEpXZYsyeFsxOfajvykrehyP1wcaXL/IQ 7xtuoHWyOe2MVa3o/rBjC9nFj3WiTkunEF+aV66Q3mSLujSRy1mFUKs9kJM3pLwF9LMYXq 7TMu74hG6R0XyYI4lTeQVmUk9YnUjBs= Date: Fri, 7 Oct 2022 16:43:23 +0200 From: Jan Hubicka To: Qing Zhao Cc: Richard Biener , Martin =?iso-8859-2?Q?Li=B9ka?= , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone Message-ID: References: <137fde8c-7ade-ecc0-96f2-9ec828b4745e@suse.cz> <406C00D6-71C6-4D62-A772-448BB014A656@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > >> Probably not hard, and the IPA pass adjusting visbility could as well > >> mark the functions > >> as not to be inlined with -flive-patching=inline-only-static. > >> > >>>> > >>>> OTOH inline-only-static could disable WPA inlining and do all inlining early ... > >>> > >>> Inline-only-static ONLY inlines static functions, how can it disable WPA inlining? Don’t quite understand here. > >> > >> it's a flag so it can be used to control other things > > > > GCC has two inliners > > 1) ealry inlininer which happens at compile time and is quite > > restricted only to obvious cases (always_inline, flatten and very small > > functions) > > 2) IPA inlining happening at link-time (WPA) which is using greedy > > algorithm and makes more complicated code size/speed tradeoffs > > Indeed betwen 1 and 2 previously global functions may become static by > > resolution info (they won't currently with kernel since we do > > incremental linking). We could easily keep track of originally static > > functions and promoted to static functions and make IPA inlining to > > honnor the patch. ^^^^ I mean -flive-patching=inline-only-static flag > > Yes, this is similar as Studio compiler (an early inliner and a IPA inliner) > But I still don’t quite understand why during IPA inlining, extern functions need to be changed to static functions? > (in Studio compiler, it’s opposite, static functions are all promoted to extern functions to enable inter-procedural inlining) > Is there a file I can read to understand more details on this? In GCC WPA stage takes all compilation units and create a new combined translation unit. This has same kind of symbol table as if it came all from a single source file. So if resolution file tells us that a given symbol is not used outside the LTO bytecode (when one links final binary linker knows if there was other use and similar for shared libraries if symbol is hidden) we promote symbol to static. This lets us to optimize it better: change calling conventions, remove offline copy if all calls was inlined, propagate various information about it. Since from this moment on the whole translation unit behaves as single source file it is not problem to inline static functions cross-modle. Later we partition the combined unit to do rest of compilation in parallel and at this stage some static symbols can be changed to hidden symbols if they are used by multiple partitioning. > > > > > I however wonder how much LTO optimization would remain. If we disable > > all inter-module inlining > > Oh, wait, so, demoting “extern” functions to “static” functions in GCC’s IPA inlining is to disable inter-module inlining? > Why? Is there any technical issue with inter-module inlining in GCC? No I suppose it is just different organization of LTO from Studio compiler. Perhaps studio compiler still combine according to original source-level compilation units and then cross-module inlining of function A may cause function B to be promoted to public in a case originally both A and B were in same compilation unit and B was static? > > > > and with live patching we also disable most of > > other optimization, > > Yes, with live-patching, most of the IPA optimization need to be disabled. But this functionality is needed, right? When user requests live-patching support, > They should know that most of IPA optimization will be disabled. Question is how much useful is to biuld with -flto then. I woudl say that close to 90% of performance benefits from LTO originates from cross-module inlining. Most of code size benefits are due to - removing unreachable code, - inlining functions called once (with whole program knowledge) - removing offline function bodies if all calls has been inlined. and - identical code folding Other IPA optimizations we implement (function flags discovery, mod-ref etc.) accounts for smaller portion of perofmance & size. If you block cross-module inlininig and all kind of inter-procedural optimizations you lose, I believe, all of the goodies above except for removal of unreachable code. While this is important for some C++ code with a lot of template instantiations, I am not sure how many completely dead functions kernel has. So what use cases you expect for -flto -flive-patching=inline-only-static? Honza > > Qing > > > I think basically only unreachable code removal will > > remain and possibly some propagation of "coldness" across the code. > > > > I can implement this incrementally. > > Martin, if live patching is happy about some symbols being promoted > > static, the patch is OK. > > Honza >