From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1887 invoked by alias); 15 Dec 2004 16:36:48 -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 31505 invoked from network); 15 Dec 2004 16:32:19 -0000 Received: from unknown (HELO alwazn.tat.physik.uni-tuebingen.de) (134.2.170.157) by sourceware.org with SMTP; 15 Dec 2004 16:32:19 -0000 Received: by alwazn.tat.physik.uni-tuebingen.de (Postfix, from userid 30023) id 400323FA1; Wed, 15 Dec 2004 17:32:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alwazn.tat.physik.uni-tuebingen.de (Postfix) with ESMTP id 2EB9A76988; Wed, 15 Dec 2004 17:32:18 +0100 (CET) Date: Wed, 15 Dec 2004 16:36:00 -0000 From: Richard Guenther To: Sebastian Pop Cc: gcc@gcc.gnu.org Subject: Re: Strange IV choices? In-Reply-To: <20041215154618.GA7519@cri.ensmp.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-12/txt/msg00582.txt.bz2 On Wed, 15 Dec 2004, Sebastian Pop wrote: > On Tue, Dec 14, 2004 at 03:56:32PM +0100, Richard Guenther wrote: > > Hi! > > > > It seems that ivopts is confused by local copies of objects. > > Suppose you have some complex array managing class, the two > > functionally identical functions > > > > void arrayAssignManual(const Array<2, double, BrickViewU>& a, > > const Array<2, double, BrickViewU>& b, > > const Array<2, double, BrickViewU>& c, > > const Array<2, double, BrickViewU>& d, > > const Interval<2> &I) > > { > > int ie = I[0].length(); > > int je = I[1].length(); > > for (int j=0; j > for (int i=0; i > a(i,j) = b(i,j)+c(i,j)+d(i,j); > > } > > > > and > > > > void arrayAssignManualCopy(const Array<2, double, BrickViewU>& a_, > > const Array<2, double, BrickViewU>& b_, > > const Array<2, double, BrickViewU>& c_, > > const Array<2, double, BrickViewU>& d_, > > const Interval<2> &I) > > { > > Array<2, double, BrickViewU> a(a_), b(b_), c(c_), d(d_); > > int ie = I[0].length(); > > int je = I[1].length(); > > for (int j=0; j > for (int i=0; i > a(i,j) = b(i,j)+c(i,j)+d(i,j); > > } > > > > get optimized vastly different. While the first one gets an > > inner loop with > > > > > In the second case the analyzer produces a scev_not_known element: > > (analyze_scalar_evolution > (loop_nb = 1) > (scalar = ostride_192) > (get_scalar_evolution > (scalar = ostride_192) > (scalar_evolution = )) > (analyze_initial_condition > (loop_phi_node = > ostride_192 = PHI ;) > (init_cond = ostride_125)) > (analyze_evolution_in_loop > (loop_phi_node = ostride_192 = PHI ;) > (evolution_function = scev_not_known)) > (set_scalar_evolution > (scalar = ostride_192) > (scalar_evolution = ostride_192)) > ) > > This situation is generated by the following code: > > # ostrideD.165952_5 = PHI <1(0)>; > D.166161_150 = (*dD.166162_151)[1]; > ostrideD.165952_125 = ostrideD.165952_5 * D.166161_150; > loop > # ostrideD.165952_192 = PHI ; > D.166161_358 = (*dD.166162_356)[1]; > ostrideD.165952_362 = ostrideD.165952_192 * D.166161_358; > endloop > > the above code is the same as: > > a = loop-phi (someconstant, a * T[1]) > > that is an exponential evolution with an undetermined step: T[1], and > these are not handled. As this is completely equivalent code apart from using a local on stack copy of the Array structure, do you agree that some earlier optimization pass must be messing something up here? Disabling DOM leads to similar code for both cases, but ivopts doesn't seem to do anything in this case. Also, all element access with operator()(int i, int j) are of the form data[i+j*stride], so they are definitely not exponential. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/