aboutsummaryrefslogtreecommitdiff
path: root/libquadmath
diff options
context:
space:
mode:
authorRichard Biener <rguenther@suse.de>2023-02-13 14:41:24 +0100
committerRichard Biener <rguenther@suse.de>2023-02-13 15:57:09 +0100
commit72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1 (patch)
tree6d02d7c7cac6ba51a7b0dac3846ef5972f8bd810 /libquadmath
parent6436add49ed9ecf74f1f01b4fe18961df4f3e83d (diff)
downloadgcc-72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1.zip
gcc-72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1.tar.gz
gcc-72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1.tar.bz2
tree-optimization/28614 - high FRE time for gcc.c-torture/compile/20001226-1.c
I noticed that for gcc.c-torture/compile/20001226-1.c even -O1 has around 50% of the compile-time accounted to FRE. That's because we have blocks with a high incoming edge count and can_track_predicate_on_edge visits all of them even though it could stop after the second. The function is also called repeatedly for the same edge. The following fixes this and reduces the FRE time to 1% on the testcase. PR tree-optimization/28614 * tree-ssa-sccvn.cc (can_track_predicate_on_edge): Avoid walking all edges in most cases. (vn_nary_op_insert_pieces_predicated): Avoid repeated calls to can_track_predicate_on_edge unless checking is enabled. (process_bb): Instead call it once here for each edge we register possibly multiple predicates on.
Diffstat (limited to 'libquadmath')
0 files changed, 0 insertions, 0 deletions