------- Comment #10 from rakdver at gcc dot gnu dot org 2006-08-27 14:56 ------- (In reply to comment #8) > The problem is still visible on the mainline, unrolling the loop on the tree > level pessimizes the generated code. Zdenek, maybe you can have a look at > this > (testcase in comment #5).
I probably do not understand what the problem is supposed to be: In auto_unrolled_knight_count8, the loop is fully unrolled (i.e., the loop ceases to exist), and as expected, constant propagation makes sure that the compile-time resolvable conditions are eliminated. In auto_unrolled_knight_count9, the number of unrollings necessary to fully unroll the loop (9) is considered too high, hence the loop gets only partially unrolled (the body of the loop is copied three times). This time, there are no compile-time resolvable conditions. If you really want even large loops to be unrolled, you may play with --param max-completely-peeled-insns and --param max-completely-peel-times parameters. There were thoughts about providing pragmas to enable requiring more unrolling just for specific loops, but as far as I know, nobody is working on that just now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
