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.
