GSoC: possible IPA-ICF project direction

[Richard Biener]

On Mon, 14 Sep 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 wonder if one class of issues would go away if we'd use the ICF
leader only for the offline copy code generation but keep all original
copies for the purpose of IPA optimizations, in particular we'd end
up always inlining the original copy and create IPA clones off it.

ISTR we talked about separate bodies for offline copies in the context
of GNU extern inline functions which have one offline body and one
body for inlining (we're dropping one on the floor currently when
both are visible IIRC).

> 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.
>
> Thanks,
> Rohith
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)