From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28138 invoked by alias); 4 Aug 2005 13:37:03 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28039 invoked by uid 48); 4 Aug 2005 13:36:39 -0000 Date: Thu, 04 Aug 2005 13:37:00 -0000 Message-ID: <20050804133639.28038.qmail@sourceware.org> From: "amylaar at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050412154215.20969.amylaar@gcc.gnu.org> References: <20050412154215.20969.amylaar@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/20969] unrolling does not take target register pressure into account. X-Bugzilla-Reason: CC X-SW-Source: 2005-08/txt/msg00443.txt.bz2 List-Id: ------- 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