[Bug tree-optimization/59299] New: We do not sink loads

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59299

            Bug ID: 59299
           Summary: We do not sink loads
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org

When fixing PR57517 I noticed that we don't sink loads leading to that PR

int x[1024], y[1024], z[1024], w[1024];
void foo (void)
{
  int i;
  for (i = 1; i < 1024; ++i)
    {
      int a = x[i];
      int b = y[i];
      int c = x[i-1];
      int d = y[i-1];
      if (w[i])
        z[i] = (a + b) + (c + d);
    }
}

results in

  <bb 4>:
  # i_18 = PHI <i_15(3), 1(2)>
  a_5 = x[i_18];
  b_6 = y[i_18];
  _7 = i_18 + -1;
  c_8 = x[_7];
  d_9 = y[_7];
  _10 = w[i_18];
  if (_10 != 0)
    goto <bb 5>;
  else
    goto <bb 8>;

  <bb 8>:
  goto <bb 6>;

  <bb 5>:
  _11 = a_5 + b_6;
  _12 = c_8 + d_9;
  _13 = _11 + _12;
  z[i_18] = _13;

  <bb 6>:
  i_15 = i_18 + 1;
  if (i_15 != 1024)
    goto <bb 3>;
  else
    goto <bb 7>;

instead of

  <bb 4>:
  # i_18 = PHI <i_15(3), 1(2)>
  _10 = w[i_18];
  if (_10 != 0)
    goto <bb 5>;
  else
    goto <bb 8>;

  <bb 8>:
  goto <bb 6>;

  <bb 5>:
  a_5 = x[i_18];
  b_6 = y[i_18];
  _7 = i_18 + -1;
  c_8 = x[_7];
  d_9 = y[_7];
  _11 = a_5 + b_6;
  _12 = c_8 + d_9;
  _13 = _11 + _12;
  z[i_18] = _13;

  <bb 6>:
  i_15 = i_18 + 1;
  if (i_15 != 1024)
    goto <bb 3>;
  else
    goto <bb 7>;

note that we eventually sink all computations into the if arm but only
stop at the loads.

tree-ssa-sink.c says:

@@ -294,8 +285,6 @@ statement_sink_location (gimple stmt, ba
      be seen by an external routine that needs it depending on where it gets
      moved to.

-     We don't want to sink loads from memory.
-
      We can't sink statements that end basic blocks without splitting the
      incoming edge for the sink location to place it there.

but doesn't give a good reason IMHO.

I have a simple patch.