Hi Martin, Thank you, and thanks to Honza as well. I'm glad the direction makes sense, and I'd like to scope it as a 350-hour project.
I'll follow up in the next few days with a more concrete technical plan and a few questions for Honza on the parts that need his judgement. Thanks, Rohith On Fri, Oct 23, 2026 at 7:57 PM Martin Jambor <[email protected]> wrote: > Hello, > > sorry that it took us so long to respond. > > On Mon, Sep 14 2026, Rohith Kapelli wrote: > > Hello, > > > > I've been working on GCC for the last few months, with four merged > patches in RTL simplification (PR125683), AArch64 (PR123951), and IPA-ICF > (PR119006 and PR123227). I was also granted Write After Approval on > September 8, sponsored by Richard Biener. > > > > While working on PR119006 and PR123227, I started looking at a broader > pattern in IPA-ICF. PR117432, PR115277, PR119006 and PR123227 expose cases > where ICF's equivalence checks (sem_function::equals_wpa and func_checker) > either miss, or do not preserve, informations that can matter after > functions are merged. > > > > For PR119006, the immediate fix was to decline the problematic merge. On > a libstdc++ LTO workload, it declines 25 merges at -O2 and 29 at -Os, with > measured .text costs of 264 and 2188 bytes. Most of them (18 of 25 at -O2) > are stream accessors such as rdbuf and is_open, merged across different > template instantiations. This seems particularly relevant given Honza's > comment 12 in PR119006 about the importance of merging template > instantiations. > > > > I also explored the alternative of keeping the merge and making the > surviving body conservative. My prototype fixed the PR119006 reproducer > while keeping the merge, but it fired zero times on the libstdc++ workload. > I also found that retyping an SSA name in place fails verify_ssa when the > name has a symbol, so a correct implementation would likely need fresh SSA > names and use redirection. > > > > This led me to a possible GSoC project: build a complete inventory of > the properties ICF needs to compare, including properties it currently > misses, and classify each one as harmless if it differs, something that can > be made conservative, or something that must block the merge. I would then > add targeted tests and measurements for each case. The > rewrite/normalization part could be a stretch goal rather than the core > deliverable. > > > > I would also like to measure the cost of losing information such as > array bounds, particularly whether it affects object-size based diagnostics > or fortification. > > > > Would this direction be interesting as a GCC GSoC project, and would you > see it fitting better as a 175-hour or 350-hour project? I would also > appreciate any suggestions on who might be a good mentor for the IPA-ICF > side. > > > > I know this is early for GSoC, but I wanted to get the direction right > before the project ideas disccusion. > > We have discussed this with Honza yesterday and we have concluded that > this would indeed be a useful and good GSoC project (and that Honza and > as a backup me would be willing to mentor it). It is (still) a bit early > but > the direction is right. > > Thanks, > > Martin > >
