[Bug tree-optimization/56817] [4.8/4.9 Regression] ICE in hide_evolution_in_other_loops_than_loop

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-03 11:46:27 UTC ---
Unfortunately seems to regress some testcases code-quality wise.

FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_HugeMallocTest
Ident((char*
)malloc(size))[-1] = 0 output pattern test, should match is located 1 bytes to
t
he left of 4299161600-byte
FAIL: g++.dg/tree-ssa/ehcleanup-1.C -std=gnu++98  scan-tree-dump-times
ehcleanup
1 "Removing unreachable" 4
FAIL: g++.dg/tree-ssa/ehcleanup-1.C -std=gnu++11  scan-tree-dump-times
ehcleanup
1 "Removing unreachable" 4


FAIL: gcc.dg/vect/pr20122.c scan-tree-dump-times vect "vectorized 1 loops" 3
FAIL: gcc.dg/vect/pr38529.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
FAIL: gcc.dg/vect/vect-104.c scan-tree-dump-times vect "possible dependence
betw
een data-refs" 1
FAIL: gcc.dg/vect/vect-65.c scan-tree-dump-times vect "vectorized 2 loops" 1
FAIL: gcc.dg/vect/vect-double-reduc-6.c scan-tree-dump-times vect "OUTER LOOP
VE
CTORIZED" 1
FAIL: gcc.dg/vect/pr20122.c -flto  scan-tree-dump-times vect "vectorized 1
loops
" 3
FAIL: gcc.dg/vect/pr38529.c -flto  scan-tree-dump-times vect "OUTER LOOP
VECTORI
ZED" 1
FAIL: gcc.dg/vect/vect-104.c -flto  scan-tree-dump-times vect "possible
dependen
ce between data-refs" 1
FAIL: gcc.dg/vect/vect-65.c -flto  scan-tree-dump-times vect "vectorized 2
loops
" 1
FAIL: gcc.dg/vect/vect-double-reduc-6.c -flto  scan-tree-dump-times vect "OUTER 
LOOP VECTORIZED" 1
FAIL: gcc.dg/vect/no-section-anchors-vect-65.c scan-tree-dump-times vect
"vector
ized 2 loops" 1

that's because we unroll more (outer) loops :/  For example in pr20122.c
the loop in main:

Loop 2 iterates 24 times.
Loop 2 iterates at most 24 times.
Loop 1 iterates 8 times.
Loop 1 iterates at most 8 times.
Estimating sizes for loop 1
 BB: 6, after_exit: 0
  size:   2 if (k_1 <= 7)
   Exit condition will be eliminated in peeled copies.
 BB: 5, after_exit: 1
  size:   1 k_10 = k_1 + 1;
   Induction variable computation will be folded away.
 BB: 4, after_exit: 1
  size:   2 if (i_2 <= 23)
   Constant conditional.
 BB: 7, after_exit: 1
 BB: 3, after_exit: 1
  size:   1 Kernel[k_1][i_2] = 0;
  size:   1 i_9 = i_2 + 1;
   Induction variable computation will be folded away.
size: 7-6, last_iteration: 2-0
  Loop size: 7
  Estimated size after unrolling: 6

where

  size:   1 i_9 = i_2 + 1;
   Induction variable computation will be folded away.

is not true - this is not an induction variable of the outer loop.

Ah, the evolution in the outer loop is simply '24'.

So back to the testcase .. in fact SSA form is invalid at the time we query
the loop size estimate!  We peel loop 2 once which fails to update SSA
form properly.  That is because we then proceed to its outer loop 1
which walks over loop children loop bodies computing SCEV info and thus
relying on up-to-date SSA form.  That cannot work.  In fact this asks
for one of my very old "cleanups" - compute sizes up-front, for all of
the nest.