On 11/19/24 5:27 AM, Richard Biener wrote:
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. Re-posted with testsuite adjustments (original from July). Bootstrapped and tested on x86_64-unknown-linux-gnu. OK? Thanks, Richard. 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.
LGTM. jeff