Hi! Four things:
On 2023-09-10T23:25:06+0200, Jan Hubicka via Gcc <gcc@gcc.gnu.org> wrote: >> On 2023-09-07T19:00:49-0400, James Hu via Gcc <gcc@gcc.gnu.org> 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-compiler-collection-gcc). >> > I was curious about working on this project, but wanted to check on the >> > 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, >> <https://gcc.gnu.org/wiki/cauldron2023>, I noticed there's going to be a >> presentation on "Incremental LTO in GCC" (Michal Jireš), >> <https://gcc.gnu.org/wiki/cauldron2023#cauldron2023talks.incremental_lto_in_gcc>. 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=1 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 <gcc@gcc.gnu.org> 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 incremental > 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üße Thomas >> > If not, what would be the appropriate method to contact the >> > mentor (Jan Hubička)? >> >> He's reading this list, but I've now also put Honza in CC. >> >> >> Grüße >> Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
