[Bug tree-optimization/34723] Summing variable should be initialized to the first member before the loop

["law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
Andrew, no.

4.2 didn't muck things up at all.  The 4.2 code is clearly better (unless
you're vectorizing the loop).

What's happening is the IV code changes the loop structure enough that
VRP2/DOM2 are unable to peel the iteration off the loop.  

In gcc-4.2, just prior to VRP2 we have:
  # BLOCK 2 freq:1000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # SUCC: 3 [100.0%]  (fallthru,exec)

 # BLOCK 3 freq:10000
  # PRED: 3 [90.0%]  (dfs_back,true,exec) 2 [100.0%]  (fallthru,exec)
  # ivtmp.43_3 = PHI <ivtmp.43_5(3), 0(2)>;
  # val_16 = PHI <val_11(3), 0(2)>;
<L0>:;
  D.1880_7 = MEM[symbol: table, index: ivtmp.43_3]{table[i]};
  D.1881_8 = (unsigned char) D.1880_7;
  val.1_9 = (unsigned char) val_16;
  D.1883_10 = val.1_9 + D.1881_8;
  val_11 = (char) D.1883_10;
  ivtmp.43_5 = ivtmp.43_3 + 1;
  if (ivtmp.43_5 != 10) goto <L0>; else goto <L2>;
  # SUCC: 3 [90.0%]  (dfs_back,true,exec) 4 [10.0%]  (loop_exit,false,exec)


VRP threads the jump through the backedge for the first iteration of the loop
resulting in:
 # BLOCK 2 freq:1000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  goto <bb 5> (<L8>);
  # SUCC: 5 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:9000
  # PRED: 5 [100.0%]  (fallthru) 3 [88.9%]  (true,exec)
  # ivtmp.43_3 = PHI <ivtmp.43_23(5), ivtmp.43_5(3)>;
  # val_16 = PHI <val_22(5), val_11(3)>;
<L0>:;
  D.1880_7 = MEM[symbol: table, index: ivtmp.43_3]{table[i]};
  D.1881_8 = (unsigned char) D.1880_7;
  val.1_9 = (unsigned char) val_16;
  D.1883_10 = val.1_9 + D.1881_8;
  val_11 = (char) D.1883_10;
  ivtmp.43_5 = ivtmp.43_3 + 1;
  if (ivtmp.43_5 != 10) goto <L0>; else goto <L2>;
  # SUCC: 3 [88.9%]  (true,exec) 4 [11.1%]  (loop_exit,false,exec)

  # BLOCK 4 freq:1000
  # PRED: 3 [11.1%]  (loop_exit,false,exec)
  # val_2 = PHI <val_11(3)>;
<L2>:;
  D.1884_13 = (int) val_2;
  return D.1884_13;
  # SUCC: EXIT [100.0%]

  # BLOCK 5 freq:1000
  # PRED: 2 [100.0%]  (fallthru,exec)
  # ivtmp.43_17 = PHI <0(2)>;
  # val_1 = PHI <0(2)>;
<L8>:;
  D.1880_18 = MEM[symbol: table, index: ivtmp.43_17]{table[i]};
  D.1881_19 = (unsigned char) D.1880_18;
  val.1_20 = (unsigned char) val_1;
  D.1883_21 = val.1_20 + D.1881_19;
  val_22 = (char) D.1883_21;
  ivtmp.43_23 = ivtmp.43_17 + 1;
  goto <bb 3> (<L0>);
  # SUCC: 3 [100.0%]  (fallthru)

Which will ultimately compile down to the efficient code where the first
iteration has been peeled off.

If we look at the trunk, DOM2/VRP2 have had the order changed, so if we look at
the code immediately prior to DOM2 we have:

 <bb 2>:
  ivtmp.10_16 = (unsigned long) &table;
  _12 = (unsigned long) &MEM[(void *)&table + 10B];
  goto <bb 4>;

  <bb 3>:

  <bb 4>:
  # val_14 = PHI <val_8(3), 0(2)>
  # ivtmp.10_18 = PHI <ivtmp.10_17(3), ivtmp.10_16(2)>
  _13 = (void *) ivtmp.10_18;
  _4 = MEM[base: _13, offset: 0B];
  _5 = (unsigned char) _4;
  val.0_6 = (unsigned char) val_14;
  _7 = _5 + val.0_6;
  val_8 = (char) _7;
  ivtmp.10_17 = ivtmp.10_18 + 1;
  if (ivtmp.10_17 != _12)
    goto <bb 3>;
  else
    goto <bb 5>;

Note how the test to go back to the top of the loop has changed.  It's no
longer testing a simple integer counter, which threading handled nicely. 
Instead it's a more complex test involving two objects.  And neither DOM2 nor
VRP2 are able to untangle it to get the code we want.

ISTM this  should have a regression marker and attached to the jump threading
meta-bug.  



_