https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126904
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- [I’ve posted this here since the context is here, but am happy to do so in the lists if it’s a better fit.] I have a prototype for doing value numbering for the backwards threader and wanted to see if there's appetite for continuing down this path. I tried a few different failed and/or expensive, and settled on extending the SCCVN framework to do path VN. Basically, value number the entire function on entry to the threader, and on each path candidate, overlay the value numbers for the path on top. SCCVN already has unwinding machinery, so this works rather well. When a new candidate path is encountered, we roll back, and overlay the new path VNs again. We'd have a fix cost per threader, value numbering the whole function, and then the cost of overlaying each path, and of course solving the paths with ranger which will be more expensive because we'd get a lot more candidate paths. I've been able to abstract this cleanly so that core SCCVN is mostly untouched, and the touched bits are easy to see with a "path_vn_mode" flag. Unfortunately this doesn't come for free. In preliminary tests this incurrs a 2.84% compile time performance cost for the whole compiler because the threader is 131% slower. Of this time, 36% is value numbering the functions (fixed cost), and 28% is overlaying the paths. The rest is solving the paths. In exchange for this, the backwards threader threads 55406 more jumps in my .ii files and DOM 35237 fewer, for 3.4% more jumps threaded overall. So, serious gains IMO. Is this worth pursuing, or is this crazy? If the former, we could deploy a version of this in this release and see where it goes? We can always pull it out?
