Open sergisiso opened 1 year ago
I started #1844 to fix these issues. I could deal with the duplicated declarations when the same kernel is in multiple invokes in the same file and a more subtle issues I found when psy.gen is called multiple times.
But I need your opinion how to solve issues with missing symbols inside the inlined routines. The problem is when the kernel code uses a globally imported variable. e.g.:
module dg_inc_matrix_vector_kernel_mod
use constants_mod, only : i_def, r_single, r_double
....
contains
subroutine dg_inc_matrix_vector_code_r_single(cell, ...)
...
real(kind=r_single), dimension(undf2), intent(in) :: x
...
When this routine is inlined the r_single is undeclared in the _psy.f90 file. There is a rule/check that no global variables are used inside inlined kernels but this is just checking the code and not the declarations kinds. I could:
1) Always import r_single and r_double in the psy module. This will solve it for my case but will potentially fail for some other in the future. 2) Check the imported symbols and bring them to the psy module. But I am not sure if having no global symbols in kernel code is a PSyKAl rule that makes ensuring the kernel is thread_safe easier to verify. Although kind symbols are safe. So should I made and exception for them? 3) Make the PSyclone check fail for this kernels because of the global import. Then they will need to be written as:
module dg_inc_matrix_vector_kernel_mod
....
contains
subroutine dg_inc_matrix_vector_code_r_single(cell, ...)
use constants_mod, only : i_def, r_single, r_double
...
real(kind=r_single), dimension(undf2), intent(in) :: x
...
this will require updating a few LFRic kernel code.
@rupertford @arporter @TeranIvy what do you think?
I think we should allow/make an exception for kind parameters. In #924 I copy any imports over to the call site, even if they are in module scope.
I think we should allow/make an exception for kind parameters. In https://github.com/stfc/PSyclone/issues/924 I copy any imports over to the call site, even if they are in module scope.
Ok, I will copy to psy the symbols used in the kind parameter.
Remaining issues after merging #1968 gravitywave_not_inlined.txt gungho_not_inlined.txt
I updated the issue title and description with the current inlining stats for gungho_model LFRic miniapp
Updated March 2024, the current stats are:
Inline transformations successful 502 Inline transformations failed 139:
Inline MATMUL intrinsic successful 64 Inline MATMUL intrinsic failed 73