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
