aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorRichard Biener <rguenther@suse.de>2024-09-25 10:38:12 +0200
committerRichard Biener <rguenth@gcc.gnu.org>2024-09-26 14:26:00 +0200
commit942bbb2357656019caa3f8ebd2d23b09222f039a (patch)
treea3000ab35cc965395091bebdc37c3bcb13bc4650 /libgcc
parente4a58b6f28383cb40e4fa287cc7dad43bafb85b2 (diff)
downloadgcc-942bbb2357656019caa3f8ebd2d23b09222f039a.zip
gcc-942bbb2357656019caa3f8ebd2d23b09222f039a.tar.gz
gcc-942bbb2357656019caa3f8ebd2d23b09222f039a.tar.bz2
tree-optimization/114855 - speed up dom_oracle::register_transitives
dom_oracle::register_transitives contains an unbound dominator walk which for the testcase in PR114855 dominates the profile. The following fixes the unbound work done by assigning a constant work budget to the loop, bounding the number of dominators visited but also the number of relations processed. This gets both dom_oracle::register_transitives and get_immediate_dominator off the profile. I'll note that we're still doing an unbound dominator walk via equiv_set in find_equiv_dom at the start of the function and when we register a relation that also looks up the same way. At least for the testcase at hand this isn't an issue. I've also amended the guard to register_transitives with the per-basic-block limit for the number of relations registered not being exhausted. PR tree-optimization/114855 * params.opt (--param transitive-relations-work-bound): New. * doc/invoke.texi (--param transitive-relations-work-bound): Document. * value-relation.cc (dom_oracle::register_transitives): Assing an overall work budget, bounding the dominator walk and the number of relations processed. (dom_oracle::record): Only register_transitives when the number of already registered relations does not yet exceed the per-BB limit.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions