[LLVMdev] Performance problems with FORTRAN allocatable arrays

Wonsun Ahn wonsun.ahn at gmail.com
Wed Feb 15 04:41:27 PST 2012

I've noticed that LLVM does a bad job of optimizing array indexing
code for FORTRAN arrays declared using the ALLOCATABLE keyword.

For example if you have something like the following:

ALLOCATE( QAV( -2:IMAX+2,-2:JMAX+2,-2:KMAX+2,ND) )
DO L = 1, 5
   DO K = K1, K2
      DO J = J1, J2
         DO I = I1, I2
            II  =  I + IADD
            IBD = II - IBDD
            ICD = II + IBDD

            QAV(I,J,K,L) = R6I * (2.0D0 * Q(IBD,J,K,L,N) +
>                                     5.0D0 * Q( II,J,K,L,N) -
>                                             Q(ICD,J,K,L,N))
         END DO
      END DO

Most of the code needed to calculate the address of QAV(I,J,K,L)
should be hoisted out of the loop since J, K, and L are constant
inside the loop. But I'm not seeing this happening because LLVM's
alias analysis cannot distinguish between the loads of the array
dimensions for QAV and the store to QAV(I,J,K,L). I've tried all the
alias analyses available in the standard distribution, including type
based analysis and scalar evolution. But if you think about it, the
array dimensions of QAV is 'metadata' and should not alias with any
actual accesses in the program. I've compiled the same code with GCC
and it was able to hoist most of the address calculations out as
expected. GCC was able to hoist address calculations for Q also.

This is an actual piece of code in SPECCPU2006 437.leslie3d and the
loop I analyzed is in line 1630 of file tml.f. 437.leslie3d suffers
horrible performance problems because of this and similar problems.

Is there anyway to enable this optimization? Is there a way to flag in
the IR that a particular locations is array dimension meta data?


More information about the llvm-dev mailing list