From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 879E1385DC15; Fri, 20 Aug 2021 14:57:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 879E1385DC15 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id C07501FE23; Fri, 20 Aug 2021 14:57:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1629471468; h=from:from:reply-to: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=/jNyWixeG4fSFyGqUq7qOCG4G5U7qEnP2Ys3Zmpa3n0=; b=rojdn3bEfEbX3F+UUwiiQgcEgm/FgQsv2+02Aj5Xb6P1FDNWDUSLnH2UcSVaG2xzBJt3un Py1i7ZRDqFAqMXkjkXwoJNWP/dH9iMascskOe0noPsUwDHFPo3NF73SVIb4RNTwbN3T+oC hvWAY2RvNXAXtMQpWbYou0pYvJuiXg8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1629471468; h=from:from:reply-to: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=/jNyWixeG4fSFyGqUq7qOCG4G5U7qEnP2Ys3Zmpa3n0=; b=yEqi/3UquzZEhtGrGVY9H1uKWRK5w4peUP+R2AGscC8wc8ex8MRHvpB59CRFC5nkaESvef ds6TLatIVHsicDCw== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 9B2BF13AFC; Fri, 20 Aug 2021 14:57:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id HmKFJOzCH2FuLAAAGKfGzw (envelope-from ); Fri, 20 Aug 2021 14:57:48 +0000 Subject: Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c) To: Richard Biener Cc: GCC Mailing List , GCC Patches , Segher Boessenkool , Giuliano Belinassi References: <20210511145904.GM10366@gate.crashing.org> <20210512121248.GU10366@gate.crashing.org> <5f13a740-5eff-886f-2b29-52a305fdf3b1@suse.cz> <03febb0f-16fa-4048-6680-438a63b11dcf@suse.cz> <5114b886-6b32-90ac-38ac-ac549950f8dc@suse.cz> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <028bdfc4-f1bd-9eda-5dc1-cedc8d1812b0@suse.cz> Date: Fri, 20 Aug 2021 16:57:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 14:58:00 -0000 On 6/1/21 3:19 PM, Richard Biener wrote: > On Tue, Jun 1, 2021 at 1:25 PM Martin Liška wrote: >> >> On 6/1/21 9:42 AM, Richard Biener wrote: >>> On Tue, Jun 1, 2021 at 9:33 AM Martin Liška wrote: >>>> >>>> @Richi: Can you please reply to this email? >>> >>> Not sure what I should add here? Honza suggested to mangle the >>> promoted symbol names. >> >> Sure and I sent a patch for that. >> >>> I don't >>> really like the idea to compile multiple TUs into one object. Also >> >> What's problematic is that we'll have to wait for one another release to make it useful >> (if you don't want to build the current master with a snapshot compiler). > > IMHO it's a bugfix. Note that I'm not sure what the intent of the change is. > If it is to speedup bootstrap then using LTO bootstrap would do the trick > as well (and better) if we'd simply process all of libbackend.a this way > (and thus avoid re-linking that once for each frontend). When building a GCC package, we intentionally re-link them with all FEs. > If it is to speedup > dev (re-)builds then dragging in more files will make it build longer since > for example insn-recog.c may be unchanged but gimple-match.c not. Yes, the original motivation was a speed up of a dev. build and yes, the shown example is problematic. Right now, I'm leaving that as I'm not interested enough in the parallel build of a simple source file. Martin > >>> +LTO_LINKER_FLAGS = -flto=auto --param=lto-partitions=16 >>> -flinker-output=nolto-rel -r >>> >>> why hard-code to 16 partitions? You're side-stepping the driver >>> diagnostic by doing >>> compile & link separately, but in the end we're going to want sth like Giulianos >>> -fparallel-compile that works transparently from within the driver, so >>> the "manual" >>> operation should try to follow that or alternatively a driver-only >>> wrapper around the >>> "manual" processing could be added whose implementation can be optimized later. >> >> All right. Do you want me refreshing his -fparallel-compile option introduction? > > I'm not sure if we've arrived at mergeable state - but if it's > reasonably possible > to hide s/-fparallel-compile/-flto -r -flinker-output=nolto-rel/ split > into compile & link > parts (avoiding the diagnostic on -flinker-output) in the driver then > I think that's > a very reasonable first step (after fixing the symbol privatization issue). The > GSOC project then was to elide the IL streaming from the high-level operation. > > Richard, > >>> >>> Why do you use -flto=auto? There should be a jobserver active. >> >> Yes, that should not be needed. >> >> Martin >> >>> >>>> On 5/21/21 10:43 AM, Martin Liška wrote: >>>>> On 5/20/21 2:54 PM, Richard Biener wrote: >>>>>> On Thu, May 20, 2021 at 2:34 PM Martin Liška wrote: >>>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> I've got a patch candidate that leverages partial linking for a couple of selected object files. >>>>>>> >>>>>>> I'm sending make all-host- jX results for my machine: >>>>>>> >>>>>>> before: 3m18s (user 32m52s) >>>>>>> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/1dd5eae5001295ba0230a689f7edc67284c9b742/gcc-all-host.svg >>>>>>> >>>>>>> after: 2m57m (user 35m) >>>>>>> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/d659b2187cf622167841efbbe6bc93cb33855fa9/gcc-all-host-partial-lto.svg >>>>>>> >>>>>>> One can utilize it with: >>>>>>> make -j16 all-host PARTIAL_LTO=1 >>>>>>> >>>>>>> @Segher, Andrew: Can you please measure time improvement for your slow bootstrap? >>>>>>> One can also tweak --param=lto-partitions=16 param value. >>>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> You're LTO linking multiple objects here - that's almost as if you >>>>>> were doing this >>>>>> for the whole of libbackend.a ... so $(OBJS)_CLFAGS += -flto and in the >>>>>> libbackend.a rule do a similar partial link trick. >>>>> >>>>> Yeah, apart from that one can't likely do partial linking for an archive: >>>>> >>>>> $ g++ -no-pie -flto=auto --param=lto-partitions=16 -flinker-output=nolto-rel -r libbackend.a >>>>> collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped >>>>> compilation terminated. >>>>> >>>>> while ld.bfd immediately finishes. >>>>> >>>>>> >>>>>> That gets you half of a LTO bootstrap then. >>>>>> >>>>>> So why did you go from applying this per-file to multiple files? Does $(LINKER) >>>>>> have a proper rule to pick up a jobserver? >>>>>> >>>>>> When upstreaming in any form you probably have to gate it on bootstrap-lto >>>>>> being not active. >>>>> >>>>> Sure, that's reasonable, we can likely detect a -flto option in $(COMPILE), right? >>>>> >>>>> One more thing I face is broken dependency: >>>>> $ make clean && make -j32 PARTIAL_LTO=1 >>>>> >>>>> g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libcody -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o gimple-match-lto.o -MT gimple-match-lto.o -MMD -MP -MF ./.deps/gimple-match-lto.TPo gimple-match.c -flto >>>>> g++ -fcf-protection -fno-PIE -c -g -DIN_GCC -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include -I/home/marxin/Programming/gcc/gcc/../libcody -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace -o generic-match-lto.o -MT generic-match-lto.o -MMD -MP -MF ./.deps/generic-match-lto.TPo generic-match.c -flto >>>>> >>>>> In file included from ./tm.h:26, >>>>> from /home/marxin/Programming/gcc/gcc/backend.h:28, >>>>> from /home/marxin/Programming/gcc/gcc/generic-match-head.c:23, >>>>> from generic-match.c:4: >>>>> /home/marxin/Programming/gcc/gcc/config/i386/i386.h:2286:10: fatal error: insn-attr-common.h: No such file or directory >>>>> 2286 | #include "insn-attr-common.h" >>>>> | ^~~~~~~~~~~~~~~~~~~~ >>>>> compilation terminated. >>>>> make: *** [Makefile:2678: generic-match-lto.o] Error 1 >>>>> make: *** Waiting for unfinished jobs.... >>>>> >>>>> In file included from ./tm.h:26, >>>>> from /home/marxin/Programming/gcc/gcc/backend.h:28, >>>>> from /home/marxin/Programming/gcc/gcc/gimple-match-head.c:23, >>>>> from gimple-match.c:4: >>>>> /home/marxin/Programming/gcc/gcc/config/i386/i386.h:2286:10: fatal error: insn-attr-common.h: No such file or directory >>>>> 2286 | #include "insn-attr-common.h" >>>>> | ^~~~~~~~~~~~~~~~~~~~ >>>>> >>>>> I explicitly added: >>>>> gimple-match.o: gimple-match.c $(generated_files) >>>>> generic-match.o: generic-match.c $(generated_files) >>>>> >>>>> But it's not obeyed. >>>>> >>>>> Martin >>>>> >>>>>> >>>>>> Richard. >>>>>> >>>>>>> Thanks, >>>>>>> Martin >>>>> >>>> >>