https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Biener <rgue...@gcc.gnu.org>: https://gcc.gnu.org/g:d1cf0d7a0f27fdd55302785f19f07d1c3f162ba5 commit r15-5646-gd1cf0d7a0f27fdd55302785f19f07d1c3f162ba5 Author: Richard Biener <rguent...@suse.de> Date: Wed Jul 10 12:45:02 2024 +0200 tree-optimization/115825 - improve unroll estimates for volatile accesses The loop unrolling code assumes that one third of all volatile accesses can be possibly optimized away which is of course not true. This leads to excessive unrolling in some cases. The following tracks the number of stmts with side-effects as those are not eliminatable later and only assumes one third of the other stmts can be further optimized. This causes some fallout in the testsuite where we rely on unrolling even when calls are involved. I have XFAILed g++.dg/warn/Warray-bounds-20.C but adjusted the others with a #pragma GCC unroll to mimic previous behavior and retain what the testcase was testing. I've also filed PR117671 for the case where the size estimation fails to honor the stmts we then remove by inserting __builtin_unreachable (). For gcc.dg/tree-ssa/cunroll-2.c the estimate that the code doesn't grow is clearly bogus and we have explicit code to reject unrolling for bodies containing calls so I've adjusted the testcase accordingly. PR tree-optimization/115825 * tree-ssa-loop-ivcanon.cc (loop_size::not_eliminatable_after_peeling): New. (loop_size::last_iteration_not_eliminatable_after_peeling): Likewise. (tree_estimate_loop_size): Count stmts with side-effects as not optimistically eliminatable. (estimated_unrolled_size): Compute the number of stmts that can be optimistically eliminated by followup transforms. (try_unroll_loop_completely): Adjust. * gcc.dg/tree-ssa/cunroll-17.c: New testcase. * gcc.dg/tree-ssa/cunroll-2.c: Adjust to not expect unrolling. * gcc.dg/pr94600-1.c: Force unrolling. * c-c++-common/ubsan/unreachable-3.c: Likewise. * g++.dg/warn/Warray-bounds-20.C: XFAIL cases we rely on unrolling loops created by new expressions and not inlined CTOR invocations.
