------- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-04 13:36 ------- (In reply to comment #13) > Strength reduction already happens before loop unrolling, but I guess > there could still be new opportunities after loop unrolling. Not sure > how significant that would be.
Unrolling really works best when it can directly work with the strength reduction information. Besides better counting and modifying DEST_ADDR givs, there is also the issue of throttling prefetching to use less preftches per cache line. E.g. whenyou have a loop with stride 4 and a cache line size of 32, when you unroll the loop by a factor of eight, instead of prefetching every cache line 8 times, you only need to prefetch it once. > > For the number of loop iterations, the plan was always that loops would > be preserved down from the tree level, and that the number of iterations > would be computed there. This hasn't happened yet, sadly. The problem is not only that we are not passed the information that was computed earlier, but also that we currently only have exact information or none at all. When there is an array access inside the loop, we might not be able to prove what the exact iteration count is, although we can make a guess that will be exact or close with a high probability. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969
