From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7517 invoked by alias); 10 Dec 2004 16:39:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7389 invoked from network); 10 Dec 2004 16:38:58 -0000 Received: from unknown (HELO dberlin.org) (68.164.203.246) by sourceware.org with SMTP; 10 Dec 2004 16:38:58 -0000 Received: from [127.0.0.1] (HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.2.6) with ESMTP-TLS id 7620846; Fri, 10 Dec 2004 11:38:58 -0500 Date: Fri, 10 Dec 2004 16:39:00 -0000 From: Daniel Berlin To: Andrew Pinski cc: Richard Guenther , gcc@gcc.gnu.org Subject: Re: Simple loops not interchanged? In-Reply-To: <6E9B793A-4AC7-11D9-8186-000A95D692F4@physics.uc.edu> Message-ID: References: <6E9B793A-4AC7-11D9-8186-000A95D692F4@physics.uc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SW-Source: 2004-12/txt/msg00369.txt.bz2 On Fri, 10 Dec 2004, Andrew Pinski wrote: > > On Dec 10, 2004, at 10:36 AM, Richard Guenther wrote: > >> Hi! >> >> I expected -ftree-loop-linear to exchange loops in >> >> double foo(double *a) >> { >> int i,j; >> double r = 0.0; >> for (i=0; i<8; ++i) >> for (j=0; j<8; ++j) >> r += a[j*8+i]; >> return r; >> } >> >> but it tells me (regardless of loop order) that >> "Won't transform loop. Optimal transform is the identity transform" >> which I cannot believe, obviously. >> >> What's going wrong here? > > First file a bug. > Second the loop linearizer loves ARRAY_REF and not INDIRECT_REF First, i probably need to change the name, since some people think it linearizes loops, which it doesn't. It performs linear transforms :P. Second, it doesn't care about array-ref or indirect-ref, actually. It just uses what the data dependence info tells it. The autovect branch has code to start to teach the data dependence analyzer about indirect_refs. MEM_REFS in their current form look big, so i'm not sure they are an optimal solution (i'd rather see array_refs be changed to allow accesses to non-array_type things. After all, this is a fricking array he's accessing, so why isn't array_ref the right thing?) --Dan