[Bug sanitizer/116267] Sanitizer extremely slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116267 --- Comment #2 from Wilson Snyder --- Created attachment 58856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58856&action=edit Vt_case_uniq_many__ALL.ii.gz
[Bug sanitizer/116267] New: Sanitizer extremely slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116267 Bug ID: 116267 Summary: Sanitizer extremely slow Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: wsnyder at wsnyder dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- The attached exposes some O(n^2) or other performance issue with -fsanitize. $ g++ -ftime-report -O0 -Wall -Wextra -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable -c -o Vt_case_unique_many__ALL.o Vt_case_unique_many__ALL.ii TOTAL : 0.81 0.92 1.73159M time g++ -ftime-report -fsanitize=address,undefined -O0 -Wall -Wextra -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable -c -o Vt_case_unique_many__ALL.o Vt_case_unique_many__ALL.ii
[Bug c++/101555] Compile slowdown in tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555 --- Comment #1 from Wilson Snyder --- Created attachment 51187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51187&action=edit Examples and runtimes
[Bug c++/101555] New: Compile slowdown in tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555 Bug ID: 101555 Summary: Compile slowdown in tree PRE Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wsnyder at wsnyder dot org Target Milestone: --- Running g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 as g++ -I. -c -Os -ftime-report -o /dev/null Vara___024root__114_0.cpp takes 297 CPU seconds. On clang version 10.0.0-4ubuntu1 it takes 37 seconds total. In GCC, 276 of 297 seconds are in the "tree PRE" stage. Splitting the large function into roughly three pieces (Vara___024root__114_0.cpp, _1 and _2) the "tree PRE" stage takes 12.7, 7.8 and 3.9 seconds (totalling 24.4). Therefore I suspect some O(n^2) issue in tree PRE. Note removing -Os makes gcc much faster, but still signifcantly slower than clang. This issue was originally reported using gcc 8.2.0 by Matheus Cavalcante at https://github.com/verilator/verilator/issues/3072
[Bug middle-end/99579] gmon.out not created with -O0 but otherwise is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99579 Wilson Snyder changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Wilson Snyder --- Thanks. Filed glibc bug here https://sourceware.org/bugzilla/show_bug.cgi?id=27576
[Bug middle-end/99579] gmon.out not created with -O0 but otherwise is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99579 --- Comment #2 from Wilson Snyder --- So glibc where to report this then?
[Bug c++/99579] New: gmon.out not created with -O0 but otherwise is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99579 Bug ID: 99579 Summary: gmon.out not created with -O0 but otherwise is Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wsnyder at wsnyder dot org Target Milestone: --- Created attachment 50382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50382&action=edit Testcase == Description Type "make" in this tarball's directory. This will show (extra lines omitted): g++ -pg -O0 -c -o Vt_case_huge_prof__main.o Vt_case_huge_prof__main.ii @ Did we get a gmon? make: [Makefile:15: x] Error 1 (ignored) g++ -pg -Os -c -o Vt_case_huge_prof__main.o Vt_case_huge_prof__main.ii @ Did we get a gmon? 4554816 28 -rw-rw-r-- 1 user user 26943 Mar 13 11:33 ./gmon.out g++ -pg -O0 -c -o Vt_case_huge_prof__main.o Vt_case_huge_prof__main__ok.ii @ Did we get a gmon? 4554816884 -rw-rw-r-- 1 user user897414 Mar 13 11:33 ./gmon.out In short gcc -pg with -O0 is not creating a gmon. The problem goes away using -Os. The problem goes away if line 60549 of ~/d/case/Vt_case_huge_prof__main.ii std::array __Vtablechg1; is changed into CData __Vtablechg1[16384]; (The original program requires a unique class, not a std::array, so using C-style arrays is unfortunately not a workaround in my application.) While this "feels" like a memory corruption sort of bug, the program is sanitizer and warning clean. == gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. == cat /etc/*release DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #12 from Wilson Snyder --- Created attachment 49515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49515&action=edit Larger testcase Attached is the larger testcase. time g++ -O2 -c -o Vtb_top__3_ii.o Vtb_top__3_ii.cpp user1m38.456s
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #10 from Wilson Snyder --- Running -O2 -fno-code-hoisting -ftime-report and I deleted the 0%/0%/0% lines: Time variable usr sys wall GGC phase parsing : 0.34 ( 1%) 0.18 ( 67%) 0.52 ( 1%) 75469 kB ( 46%) phase lang. deferred : 0.02 ( 0%) 0.01 ( 4%) 0.02 ( 0%) 3473 kB ( 2%) phase opt and generate : 38.01 ( 99%) 0.08 ( 30%) 38.12 ( 99%) 85265 kB ( 51%) |name lookup : 0.06 ( 0%) 0.02 ( 7%) 0.10 ( 0%) 3222 kB ( 2%) |overload resolution : 0.02 ( 0%) 0.01 ( 4%) 0.03 ( 0%) 3886 kB ( 2%) alias stmt walking : 0.27 ( 1%) 0.00 ( 0%) 0.34 ( 1%) 1 kB ( 0%) preprocessing : 0.05 ( 0%) 0.06 ( 22%) 0.07 ( 0%) 6448 kB ( 4%) parser (global): 0.04 ( 0%) 0.04 ( 15%) 0.12 ( 0%) 29550 kB ( 18%) parser struct body : 0.03 ( 0%) 0.02 ( 7%) 0.10 ( 0%) 10609 kB ( 6%) parser function body : 0.08 ( 0%) 0.02 ( 7%) 0.09 ( 0%) 12779 kB ( 8%) parser inl. func. body : 0.02 ( 0%) 0.03 ( 11%) 0.06 ( 0%) 3940 kB ( 2%) parser inl. meth. body : 0.05 ( 0%) 0.01 ( 4%) 0.05 ( 0%) 4949 kB ( 3%) template instantiation : 0.09 ( 0%) 0.01 ( 4%) 0.04 ( 0%) 10514 kB ( 6%) tree SSA incremental : 0.01 ( 0%) 0.01 ( 4%) 0.02 ( 0%) 6465 kB ( 4%) tree operand scan : 0.00 ( 0%) 0.01 ( 4%) 0.01 ( 0%) 1875 kB ( 1%) tree PRE : 36.36 ( 95%) 0.05 ( 19%) 36.34 ( 94%) 32604 kB ( 20%) out of ssa : 0.17 ( 0%) 0.00 ( 0%) 0.17 ( 0%) 0 kB ( 0%) combiner : 0.16 ( 0%) 0.00 ( 0%) 0.16 ( 0%) 11911 kB ( 7%) integrated RA : 0.11 ( 0%) 0.00 ( 0%) 0.12 ( 0%) 4562 kB ( 3%) initialize rtl : 0.00 ( 0%) 0.01 ( 4%) 0.00 ( 0%) 12 kB ( 0%) TOTAL : 38.37 0.27 38.67 165692 kB real0m38.707s user0m38.398s sys 0m0.292s
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #7 from Wilson Snyder --- Thanks for the quick service. I can't easily try GCC trunk, but: -O2 compile 98.61s runtime 25.76s -O2 -fno-code-hoisting compile 40.13s runtime 26.40s (+2.5%) -Os compile 4.25s runtime 23.42s (-10%) That -Os runs faster is expected as this program is generally instruction-fetch limited. I'd have expected -fno-code-hoisting to help more, compile time wise. Am I correct in understanding that the slowdown is roughly correlated to the number of "if" or "?:" statements?
[Bug c++/97623] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #1 from Wilson Snyder --- P.S. Note gcc -v and related information are comments at top of the attachment.
[Bug c++/97623] New: Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 Bug ID: 97623 Summary: Extremely slow O2 compile (>>O(n^2)) Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wsnyder at wsnyder dot org Target Milestone: --- Created attachment 49461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49461&action=edit slow.cpp The attached program compiles very slowly with -O2. It is fast with clang (FWIW). This is an shortened version of a routine taking > 10 minutes. $ gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 time g++ -O2 -c slow.cpp 6.457 (average) time g++ -Os -c slow.cpp 0.236 (average) time g++ -O2 -DNO_BOTTOM -c slow.cpp 0.560 (average) time g++ -O2 -DNO_TOP -c slow.cpp 0.702 (average) time g++ -O2 -DNO_FINAL -c slow.cpp 6.271 (average) time clang++ -O2 -c slow.cpp 0.210 (average) Note Os is much faster. The defines remove the top half of the function, or bottom half, note the time is crazy faster, one would expect the whole program to be only slightly slower than the sum of these. Removing a single statement from the bottom (-DNO_FINAL) also makes an enormous 0.21 second difference, so some algorithm is not scaling correctly. Would greatly appreciate some indication of 1. a compiler flag to bypass the bad optimization if possible, and 2. a hint as to what operator or how to avoid this as this is generated code so there's some flexibility for a workaround. Thanks.
