https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65442
Bug ID: 65442 Summary: pass_lim misses support for exit-first loops Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Consider test.c: ... #include <string.h> const char *something (void); size_t f (unsigned int n) { const char *s = something (); size_t sum = 0; size_t t; unsigned int i; if (!s) return 0; for (i = 0; i < n; ++i) { t = strlen (s); sum += t; } return sum; } ... The resulting code with -O2 -fno-tree-ch from the optimized dump is: ... f (unsigned int n) { unsigned int i; size_t t; size_t sum; const char * s; size_t _3; <bb 2>: s_6 = something (); if (s_6 == 0B) goto <bb 6>; else goto <bb 3>; <bb 3>: # sum_14 = PHI <0(2)> # i_12 = PHI <0(2)> goto <bb 5>; <bb 4>: t_9 = strlen (s_6); sum_10 = sum_1 + t_9; i_11 = i_2 + 1; <bb 5>: # sum_1 = PHI <sum_14(3), sum_10(4)> # i_2 = PHI <i_12(3), i_11(4)> if (i_2 != n_8(D)) goto <bb 4>; else goto <bb 6>; <bb 6>: # _3 = PHI <0(2), sum_1(5)> return _3; } ... The strlen is not taken out of the loop. It could be taken out of the loop, provided it's guarded with the loop condition. This PR is similar to PR65440. There the strlen is conditional in the loop body, which is entered unconditionally. Here the strlen is unconditional in the loop body, which is entered conditionally.