From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 97A6B3858C27 for ; Wed, 27 Sep 2023 00:11:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 97A6B3858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-CSE-ConnectionGUID: QzU9qpoZRmKXplChujtLXA== X-CSE-MsgGUID: H/Sj9Te8THWhhsJaHiY0wQ== X-IronPort-AV: E=Sophos;i="6.03,179,1694764800"; d="scan'208";a="20042454" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 26 Sep 2023 16:11:51 -0800 IronPort-SDR: ZBap0tVl3pQEGzeLo/1ruVkyHI5aBXwWdPOWX4r9W4amjbxeY4R5nePjX9eVTp5e+/4PUEkBBR BG3ltgpJSskefeI0c9/sHzvQOy5H3+5f8Wqbvy8sjTW/rk805EVC0LwAoEExrCChHCRWsovej3 j9RZgxYf77chInVuws2keWKq+5zTupttyNn39XvxOTNSU3BV5wgLX+P3+Ut/OiQTVVdfwNHYp0 6VgsGwLnzxrppO7gRaIXvECCR0sdoxzliEskHjrK0o/LqJZ4UVP7uw8MZeS2RwbNHHiNmxXAOP dyI= From: Thomas Schwinge To: Jan Hubicka , , James Hu CC: , Thomas Schwinge Subject: Re: Incremental LTO Project In-Reply-To: References: <87edj96shu.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/28.2 (x86_64-pc-linux-gnu) Date: Wed, 27 Sep 2023 02:11:39 +0200 Message-ID: <87il7w4gqs.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,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: Hi! Four things: On 2023-09-10T23:25:06+0200, Jan Hubicka via Gcc wrote: >> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote: >> > I noticed that adding incremental LTO was a GSoC project that was not >> > claimed this cycle ( >> > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-co= mpiler-collection-gcc). >> > I was curious about working on this project, but wanted to check on th= e >> > state of the project. >> >> Thanks for your interest! (... as a potential contributor, I presume?) >> >> > Has it already been completed? Is someone actively >> > working on it? >> >> Yesterday, when browsing the schedule of the GNU Tools Cauldron 2023, >> , I noticed there's going to be a >> presentation on "Incremental LTO in GCC" (Michal Jire=C5=A1), >> . 1. Was nice to meet you (Honza, Michal) at the Cauldron, attending the "Incremental LTO in GCC" presentation. (James: recording should become available soonish.) > Indeed Michal Jires (who is my student at Charles University) did a lot > of work on incremental LTO. He is finishing his second bachelor in > physics and then we plan to start working towards contributing it to the > mainline. Great! > His imlementation is described in thesis > https://dspace.cuni.cz/bitstream/handle/20.500.11956/183051/130360194.pdf= ?sequence=3D1 2. Talking to you after the presentation, I had mentioned that I had failed to understand how the new partitioning scheme works, when reading Michal's thesis on my way to the Cauldron. I'm happy to report that upon re-reading it on my way back home, I then did manage to understand it. ;-) 3. I had suggested that in addition to compilation flags (which you have covered, per my understanding) also the specific compiler builds should probably be taken into account (by means of 'cc1' etc. checksums, for example?), so that the cache doesn't return out-of-date results in that regard. Now I had the idea whether we maybe could simply use/modify 'ccache' for that chaching aspect, as it does exactly that: maintain a persistent cache, with user-configurable size, stale objects pruning, etc., and takes care that no stale cached objects are returned to the user. I've not spent any more detailed thoughts on that, however. > This is just a start of the project, further improvemnts will be welcome Which brings us to 4.: On 2023-09-08T07:26:20-0400, James Hu via Gcc wrote: > Ah, I see. I was interested as a contributor but outside of the official > GSoC program. But I'm assuming that because there is a talk on incrementa= l > LTO, it has already been implemented, correct? Is there anything that James could work on -- without conflicting with Michal's ongoing work? (Note that I'm just the hopefully helpful messenger here; don't know James personally.) James, I suppose it'd help if you sketched what's interesting to you in a bit more detail than just "incremental LTO", and the amount of work/time you'll be able to invest, roughly. Gr=C3=BC=C3=9Fe Thomas >> > If not, what would be the appropriate method to contact the >> > mentor (Jan Hubi=C4=8Dka)? >> >> He's reading this list, but I've now also put Honza in CC. >> >> >> Gr=C3=BC=C3=9Fe >> Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955