[Bug tree-optimization/63602] [4.9/5/6 Regression] Wrong code w/ -O2 -ftree-loop-nest-optimize

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63602

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-11-18
                 CC|                            |spop at gcc dot gnu.org
      Known to work|4.9.2                       |4.3.4
            Version|unknown                     |5.2.1
   Target Milestone|5.3                         |4.9.4
            Summary|[5/6 Regression] Wrong code |[4.9/5/6 Regression] Wrong
                   |w/ -O2 -ftree-loop-linear   |code w/ -O2
                   |                            |-ftree-loop-nest-optimize
     Ever confirmed|0                           |1
      Known to fail|                            |4.9.3

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Contrary to comment #2 it doesn't work with 4.9.2 (nor 4.8.5).  But it works
with
4.3.4 (which has non-graphite based -ftree-loop-linear).

Broken with ISL 0.12 and ISL 0.14 at least.

It seems to work on trunk, by accident I guess:

Function does not have enough loops: PARAM_GRAPHITE_MIN_LOOPS_PER_FUNCTION = 2.

number of SCoPs: 0

static bool
graphite_initialize (isl_ctx *ctx)
{
  int min_loops = PARAM_VALUE (PARAM_GRAPHITE_MIN_LOOPS_PER_FUNCTION);
  int max_bbs = PARAM_VALUE (PARAM_GRAPHITE_MAX_BBS_PER_FUNCTION);
  int nbbs = n_basic_blocks_for_fn (cfun);
  int nloops = number_of_loops (cfun);

  if (nloops <= min_loops

no idea why we have this parameter at all or why we test it with <=
(the user-facing parameter shouldn't count the loop tree root which
number_of_loops counts).

I suppose this parameter was added because with just one real loop
we don't have a nest and thus there isn't anything to optimize.

Changing the testcase to

int sx;
int bn;
int vz = 1;
int *volatile n6 = &bn;
int n;

int
main(void)
{
  for (int j = 0; j <= n; ++j)
  for (int i = 0; i < 3; ++i) {
      sx = vz;
      vz = bn;
  }
  return sx;
}

makes trunk do something but in the end it "fails" as well because the
loop doesnt' contain any references anymore.

In the end the very reason for the miscompile is likely the prephitmp_1
PHI node which maybe the out-of-SSA graphite code doesn't handle correctly.

  <bb 3>:
  # i_12 = PHI <i_8(4), 0(2)>
  # prephitmp_1 = PHI <pretmp_10(4), pretmp_9(2)>
  i_8 = i_12 + 1;
  if (i_8 != 3)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>:
  goto <bb 3>;