https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #40 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
For the record, I still think adjust_paths_after_duplication() isn't giving us
much for all the hassle it's causing.
I compared the number of threaded paths with and without it and the difference
is:
* mainline
Number of threads:
threadfull:31634
ethread:22253
thread:12048
total: 65935
* without adjust_paths_after_duplication:
Number of threads:
threadfull:30561
ethread:22253
thread:11743
total: 64557
That is, adjust_paths_after_duplication() is just saving us 2% of threaded
paths.
The above is for -O2 -fno-tree-dominator-opts which disables the DOM threader,
so DOM doesn't start picking up the slack from the lack of subpaths in the
backward threader.
