[MITgcm-devel] compiler optimization on SunOS
Jean-Michel Campin
jmc at ocean.mit.edu
Sun Feb 18 13:23:11 EST 2007
Hi,
In general, I don't think we should change the code
because of a bug in compiler optimization.
And, I would like to keep the original index range,
because the domain where cg2d_b needs to be computed is
well defined, it's evaluated correctly,
and uf & vf are initialized where they need to be.
I would propose either:
a) duplicate the code within #ifdef COMPILER_PROBLEM
and inside, do the modifuication to make this compiler happy.
b) use a lower level of optimisation for this S/R ;
but because there might be other places were the compiler
optimization is doing strange things, might even be
an option to use a lower level of optimisation for all
the compilations.
Jean-Michel
On Sun, Feb 18, 2007 at 01:56:18PM +0100, Martin Losch wrote:
> Hi there,
> I have traced down the optimization problem to this section:
> > DO K=Nr,1,-1
> > DO j=1,sNy+1
> > DO i=1,sNx+1
> > uf(i,j) = _dyG(i,j,bi,bj)*deepFacC(k)
> > & *drF(k)*_hFacW(i,j,k,bi,bj)*rhoFacC(k)
> > vf(i,j) = _dxG(i,j,bi,bj)*deepFacC(k)
> > & *drF(k)*_hFacS(i,j,k,bi,bj)*rhoFacC(k)
> > ENDDO
> > ENDDO
> > CALL CALC_DIV_GHAT(
> > I bi,bj,1,sNx,1,sNy,K,
> > I uf,vf,
> > U cg2d_b,
> > I myThid)
> > ENDDO
> When I increase the loop ranges to 1-Oly,sNy+Oly and 1-Olx,sNx+Olx,
> everything is fine even with the high optimization level. What do you
> think about increasing these loop ranges, or at least initializtion
> vf and uf properly (I didn't try yet, if that would work, too).
>
> Martin
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list