This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Strange IV choices?
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 15 Dec 2004 17:32:18 +0100 (CET)
- Subject: Re: Strange IV choices?
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<je; ++j)
> > for (int i=0; i<ie; ++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<je; ++j)
> > for (int i=0; i<ie; ++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 <ostride_362(11), ostride_125(16)>;)
> (init_cond = ostride_125))
> (analyze_evolution_in_loop
> (loop_phi_node = ostride_192 = PHI <ostride_362(11), ostride_125(16)>;)
> (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 <ostrideD.165952_362(11), ostrideD.165952_125(16)>;
> 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 <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/