http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
--- Comment #7 from davidxl <xinliangli at gmail dot com> 2011-07-05 22:51:49 UTC --- (In reply to comment #6) > Created attachment 24693 [details] > k.c.127t.uninit 1) is the complicated control flow generated by if-merging + jump-threading? 2) On the targets that have the problem, is branch cost considered cheap? 3) Looks like there are more jump-threading opportunities that can clean up the control flow, namely, (in the attached file): BLOCK 4 should be split into 4_1 and 4_2. 4_1's predecessor is BLOCK 8, and it can be merged with with BLOCK 10. The merged block (10 and 4_1) has single successor BLOCK 6. BLOCK 4_2 (predecessor is 9) is successors can be greatly simplified with a single successor BLOCK 7. Why is that not happening? With the complicated control flow, the uninit analysis is definitely confused -- requires powerful symbolic evaluation to simplify the predicates: the predicates guarding the use in BLOCK 6: (n<=9 AND m==0) OR (n <= 9 AND m != 0 AND (n <=9 OR m > 100)) OR (n > 9 AND m > 100) OR (n > 9 AND m <= 100 AND (n<=9 OR m > 100)) of course there might be other bugs in the analysis that prevent the above from formulated, but nonetheless, it is unlikely to be handled). Solution 1) fix the test case by disabling jumpthreading and if-merging 2) or maybe move the uninit analysis earlier in the pipeline. David
