https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126904
--- Comment #11 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- The patch series which I’m about to post is what I have been working on for value-number-based jump threading: the backward threader runs inside FRE, and its path solver resolves loads through SCCVN's value numbers. I have used AI to black box the path-SCCVN work (class path_vn), so I can concentrate on the backward threader and the path solver without worrying about stuff I don't understand ;-). This series only includes a skeleton path_vn that returns the function's own value numbers, which hold on every path. The comments on its methods say what a real implementation has to provide. I don't know SCCVN well enough to implement it properly, and was hoping Richi or someone else could pick it up. Everything around it is done: the SCCVN driver change, the path solver and threader hooks, threading in FRE, and the follow-ups that widen the search to loads and keep its cost down. path_vn is the one missing piece, but even without it, things work and are an improvement. The skeleton alone works surprisingly well: with --param=fre-jump-threading=1, the two FREs thread 198034 jumps over a corpus of .ii files from a stage1 bootstrap, and with DOM's threader still on, 6.82% more jumps are threaded overall, for 1.37% more compile time, counted in instructions. The series bootstraps and regtests clean with the param off. With it on, the only new failures are tests counting threads or folds in other passes' dumps. More numbers are in the commits themselves. To try it: --param=fre-jump-threading=1, and optionally --param=dom-jump-threading=0 to keep DOM and FRE from competing for threads. Would it be crazy to suggest we enable this in this release to get broader coverage, and then drop in the path-aware version next release (and nuke DOM threading in the process)? DOM's threader has to stay on until then: with the skeleton alone and DOM's threader off, 2.47% fewer jumps are threaded than today. Note that there are some follow-up enhancements that would need to go in if we enable this with path awareness (performance mostly, to reduce the search space, etc., because we start finding a *lot* of things). FWIW, I already have these enhancements ready, but figured it would distract from the core work here. I welcome a review and suggestions in this space. It was suggested in my last patches in this area that it was difficult to offer suggestions if the reviewer couldn't see where I was going with this. I hope this is clearer now :-). Short of a different direction from reviewers, I'm kinda sorta done here.
