[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