https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72850
Jeffrey A. Law <law at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P2 --- Comment #6 from Jeffrey A. Law <law at redhat dot com> --- Note that c#3-c#5 are referring to a different issue and that issue is being tracked by bz77445 (profile estimates are mucked up by early jump threading and as a result we fail to thread a multi-way branch during a later pass, which is a huge issue). -- This BZ is just a missed loop peeling opportunity and it's really not a major missed optimization. Prior to Jan's change we computed 7 statements in 6 copied blocks -- which is an indicator that there's likely not much a traditional loop optimizer could do here, so potentially creating an irreducible loop is unlikely to hurt later loop optimizations. Jan's change uses a more standard way to compute costs that is almost certainly more accurate in the general case. The net result is we guess that the resulting region will have 13 insns in 6 copied blocks and thus the perceived cost is much higher. However, there's something subtle going on here. The old heuristic was mostly concerned with how many gimple statements were in the region (and didn't look at their complexity). The new heuristic tries to estimate the number of insns the gimple statements will generate. So it's no great surprise that with the change in base (gimple statement vs RTL insn) that the heuristic gives different results sometimes. I'm leaning towards changing the default statement scale factor to account for the change in the base. That is sufficient to fix this problem, but likely won't help 77445.