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.