From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25543 invoked by alias); 20 Jan 2005 15:15:53 -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 25506 invoked by alias); 20 Jan 2005 15:15:49 -0000 Date: Thu, 20 Jan 2005 15:15:00 -0000 Message-ID: <20050120151549.25505.qmail@sourceware.org> From: "rguenth at tat dot physik dot uni-tuebingen dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041201143906.18754.pinskia@gcc.gnu.org> References: <20041201143906.18754.pinskia@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg02820.txt.bz2 List-Id: ------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-20 15:15 ------- Subject: Re: unrolling happens too late/SRA does not happen late enough On 20 Jan 2005, dberlin at dberlin dot org wrote: > Wiat, why are we running SRA twice again at all? > I can't figure this out from the bug report, other than seeing that we > "could sra c.array", but i don't see why that requires a loop opt first. We don't run sra twice. But an early loop unrolling will change f.i. for (unsigned int d=0; d<4; ++d) c.array[d] = a.array[d] * b.array[d]; to c.array[0] = a.array[0] * b.array[0]; c.array[1] = a.array[1] * b.array[1]; c.array[2] = a.array[2] * b.array[2]; c.array[3] = a.array[3] * b.array[3]; and SRA can only scalarize this variant, not if the loop is still there. That's the whole point of the loop<->sra ordering problem. And of course sra may then expose new interesting choices for iv's of outer loops - at least I think. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18754