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.

Reply via email to