(Closes #2716) Add support for module-inlining calls to polymorphic kernels/routines

[arporter]

No description provided.

[codecov]

Codecov Report

Attention: Patch coverage is 98.68421% with 5 lines in your changes missing coverage. Please review.

Project coverage is 99.87%. Comparing base (1e6b095) to head (5c72806).

Files with missing lines	Patch %	Lines
...mmon/transformations/kernel_module_inline_trans.py	97.16%	4 Missing ⚠️
src/psyclone/psyir/nodes/call.py	97.82%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2732      +/-   ##
==========================================
- Coverage   99.88%   99.87%   -0.01%     
==========================================
  Files         357      357              
  Lines       49742    49870     +128     
==========================================
+ Hits        49686    49809     +123     
- Misses         56       61       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[arporter]

As well as addressing the coverage, I need to extend the LFRic integration tests to use this new functionality.

[arporter]

Added the KernelModuleInlineTrans back into the LFRic transformation script and get a crash when trying to add the interface symbol into the symbol table.

[arporter]

This is ready for a first review. It's quite big but can wait until 3.0 is out of the door. Probably needs to be reviewed by @sergisiso.

[arporter]

In experimenting with this branch, I discovered a bug: the routines that a PUBLIC Interface maps to may themselves be declared PRIVATE in their containing module! Unfortunately, in what I've written I've assumed they must be public.

[arporter]

Trying this updated branch with LFRic (and my enhanced global.py) I now get:

Failed to module-inline routine coordinate_jacobian:
Transformation Error: routine 'coordinate_jacobian' contains accesses to 'jacobian_abr2xyz' which is declared in the same module scope. Cannot inline such a routine.

where jacobian_abr2xyz is actually a routine in the same module so we could inline it...

Also get

File '../lfric/components/science/source/kernel/geometry/chi_transform_mod.F90' does contain module 'chi_transform_mod' but PSyclone is unable to create the PSyIR of it.

This is possibly because that module contains an unsupported form of interface definitions:

  INTERFACE
    SUBROUTINE chi2xyz_interface(chi_1, chi_2, chi_3, panel_id, x, y, z)
      IMPORT :: r_def, i_def
      IMPLICIT NONE
      INTEGER(KIND = i_def), INTENT(IN) :: panel_id
      REAL(KIND = r_def), INTENT(IN) :: chi_1, chi_2, chi_3
      REAL(KIND = r_def), INTENT(OUT) :: x, y, z
    END SUBROUTINE chi2xyz_interface
  END INTERFACE

[arporter]

Attempt to do recursive inlining:

Failed to inline call jacobian_abr2xyz(alpha, beta, radius, panel_id):
Transformation Error: Routine 'jacobian_abr2XYZ_r_single' cannot be inlined because it accesses variable 'r_single' from its parent container.

but r_single is actually named in an import into the parent container => should be easy to handle.

...well, ish. It's a bit messy because there's no clean way to spot all the Symbols a bit of code uses and I don't want to duplicate what validate() does. Maybe we can use VAI?