[Flang] Assignments for arrays of a derived type are slower than GFortran

[yus3710-fj]

The execution of the following codes is slower than GFortran.

• test.f90

module d
  type mytype1
    integer :: x,y,z
  end type
end module

subroutine ddannn042(lhs,rhs)
  use d
  type(mytype1) :: rhs(:)
  type(mytype1) :: lhs(:)
  lhs = rhs
end subroutine

• main.f90

use d
implicit none

integer, parameter :: count = 4000
integer :: i,j,k
type(mytype1) :: t1(100),t2(100)
real :: start_t, end_t
interface
  subroutine ddannn042(lhs,rhs)
    use d
    type(mytype1) :: rhs(:)
    type(mytype1) :: lhs(:)
  end subroutine
end interface

call cpu_time(start_t)
do i=1,count
  do j=1,count
    call ddannn042(t1,t2)
  end do
end do
call cpu_time(end_t)

print *, end_t - start_t
end

• commands

$ flang -Ofast -mcpu=native test.f90 main.f90 && ./a.out # for A64FX/Grace
$ flang -Ofast -march=native test.f90 main.f90 && ./a.out # for Xeon

	Flang [s]	GFortran [s]
A64FX	5.2878265	0.701558948
Grace	1.0241077	0.304776996
Xeon	1.4631462	0.285580993

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: Yusuke MINATO (yus3710-fj)

The execution of the following codes is slower than GFortran.

• test.f90

module d
  type mytype1
    integer :: x,y,z
  end type
end module

subroutine ddannn042(lhs,rhs)
  use d
  type(mytype1) :: rhs(:)
  type(mytype1) :: lhs(:)
  lhs = rhs
end subroutine

• main.f90

use d
implicit none

integer, parameter :: count = 4000
integer :: i,j,k
type(mytype1) :: t1(100),t2(100)
real :: start_t, end_t
interface
  subroutine ddannn042(lhs,rhs)
    use d
    type(mytype1) :: rhs(:)
    type(mytype1) :: lhs(:)
  end subroutine
end interface

call cpu_time(start_t)
do i=1,count
  do j=1,count
    call ddannn042(t1,t2)
  end do
end do
call cpu_time(end_t)

print *, end_t - start_t
end

• commands

$ flang -Ofast -mcpu=native test.f90 main.f90 && ./a.out # for A64FX/Grace
$ flang -Ofast -march=native test.f90 main.f90 && ./a.out # for Xeon

	Flang [s]	GFortran [s]
A64FX	205.93236	0.724337995
Grace	34.432254	0.307622015
Xeon	51.895687	0.285207003

[llvmbot]

@llvm/issue-subscribers-flang-runtime

Author: Yusuke MINATO (yus3710-fj)

The execution of the following codes is slower than GFortran.

• test.f90

module d
  type mytype1
    integer :: x,y,z
  end type
end module

subroutine ddannn042(lhs,rhs)
  use d
  type(mytype1) :: rhs(:)
  type(mytype1) :: lhs(:)
  lhs = rhs
end subroutine

• main.f90

use d
implicit none

integer, parameter :: count = 4000
integer :: i,j,k
type(mytype1) :: t1(100),t2(100)
real :: start_t, end_t
interface
  subroutine ddannn042(lhs,rhs)
    use d
    type(mytype1) :: rhs(:)
    type(mytype1) :: lhs(:)
  end subroutine
end interface

call cpu_time(start_t)
do i=1,count
  do j=1,count
    call ddannn042(t1,t2)
  end do
end do
call cpu_time(end_t)

print *, end_t - start_t
end

• commands

$ flang -Ofast -mcpu=native test.f90 main.f90 && ./a.out # for A64FX/Grace
$ flang -Ofast -march=native test.f90 main.f90 && ./a.out # for Xeon

	Flang [s]	GFortran [s]
A64FX	205.93236	0.724337995
Grace	34.432254	0.307622015
Xeon	51.895687	0.285207003

[yus3710-fj]

_FortranAAssign seems to make the performance bad. Ultimately, assignments should be inlined. However, I'm thinking of improving the performance of _FortranAAssign at first because it would not be obvious that every assignment can be inlined at the moment.

[yus3710-fj]

Assignments of array elements

Flang's runtime reproduces subscripts at first and then calculates the address of elements based on the subscripts. GFortran doesn't have to reproduce subscripts because loop ivs can be subscripts as they are. In other words, Flang has to process arrays of any dimensions with a single loop while GFortran processes n-dim arrays with an n-nested loop.
My prototype introduced another route to process n-dim arrays with an n-nested loop into the runtime and cut 44% of the execution time.

Assignments of components

Flang checks the type information (e.g. the byte size and the offset of a component) in runtime while GFortran determines it in compile-time. Therefore, inlining is probably necessary to fill the performance gap.

[yus3710-fj]

#137727 improves the performance of runtime.

The measurements on Grace CPU:

w/o the patch	w/ the patch
14.685017s	0.91916656s

[klausler]

Has this bug been resolved in the current sources?