(Towards #2271, closes #2278, closes #2849) Generalise reference_accesses() and use to tidy KernelModuleInlineTrans.

[arporter]

I found I needed some of this in #2716 (while improving KernelModuleInlineTrans) so I thought I'd best do it as a separate PR.

This also fixes #2849 where we were incorrectly hoisting assignments out of loops.

[arporter]

I need to add explicit unit tests for the new reference_access() methods that I've added to Literal, CodeBlock and ScopingNode. For the moment, my implementation for ScopingNode only adds info about Symbols that appear in precision or initialisation expressions. I rely on the subsequent walk down the tree to add Symbols that are actually used (and also how they are used).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.89%. Comparing base (f534847) to head (e4c1ad3).
Report is 52 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2825   +/-   ##
=======================================
  Coverage   99.88%   99.89%           
=======================================
  Files         359      359           
  Lines       50860    50952   +92     
=======================================
+ Hits        50804    50897   +93     
+ Misses         56       55    -1     

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

[arporter]

This PR enhances the functionality of VariablesAccessInfo by adding reference_accesses methods to CodeBlock, Literal and ScopingNode. This then allows it to be used in KernelModuleInlineTrans() in place of the custom search for symbols that used to be performed there. We can probably use this functionality elsewhere but I've not investigated that here.

Ready for review. One for @hiker or @sergisiso.

[arporter]

(I've triggered the integration tests.)

[arporter]

Taking this back as both the NEMOv4 and LFRic integration tests failed :-(

[arporter]

LFRic ('with all transformations') test fails with:

algorithm/runtime_constants/physical_op_constants_mod_psy.f90:253:10:
41632

41633
  253 |       IF (psyclone_internal_cmp(geometry, geometry_planar)) THEN
41634
      |          1
41635
Error: Function 'psyclone_internal_cmp' at (1) has no IMPLICIT type

and the NEMO v.4 OpenACC kernels test fails at the final link stage:

NEMO/cfgs/SPITZ12_openacc_kernels/BLD/lib/lib__fcm__nemo.a(obs_oper.o): in function `obs_oper_obs_max_fpsize_':
14928
NEMO/cfgs/SPITZ12_openacc_kernels/WORK/obs_oper.f90:905: undefined reference to `obs_deg2dist_'
14929
NEMO/cfgs/SPITZ12_openacc_kernels/BLD/lib/lib__fcm__nemo.a(obs_oper.o): in function `obs_oper_obs_avg_h2d_init_':
14930
NEMO/cfgs/SPITZ12_openacc_kernels/WORK/obs_oper.f90:955: undefined reference to `obs_avg_h2d_rad_'
14931
NEMO/cfgs/SPITZ12_openacc_kernels/WORK/obs_oper.f90:959: undefined reference to `obs_avg_h2d_rec_'

I think the latter often means we've put OpenACC around a function call but the function itself hasn't been marked-up for GPU compilation?

[arporter]

In LFRic, we have an in-lined kernel that calls our PSyclone-generated routine but that routine hasn't been inlined:

      REAL(KIND=r_def), dimension(ndf_w2b,3) :: rad_vector_xyz

      ipanel = INT(panel_id(map_pid(1)), i_def)
      IF (psyclone_internal_cmp(geometry, geometry_planar)) THEN
        x_vector = (/1.0_r_def, 0.0_r_def, 0.0_r_def/)
        y_vector = (/0.0_r_def, 1.0_r_def, 0.0_r_def/)

Presumably, the symbol isn't being spotted by the transformation?

[arporter]

The issue seems to be that Call.reference_accesses() does not record the routine name. There is a TODO back to #2271 suggesting we need a new type of access in AccessType allowing us to capture the fact that a symbol is required at compile time. I can do this but we'll need agreement on what to call it. Currently we have:

Some suggestions:

SYMBOLIC, STATIC, COMPILE_TIME

What do @hiker and @sergisiso think?

[sergisiso]

I don't like SYMBOLIC, as any other reference is also symbolic.

I could live with STATIC and COMPILE_TIME but I don't know if they are descriptive enough (and it is similar to some of the symbol interfaces which can make it confusing).

Why don't we simply call them: CALL / CALLED

Note that before we discussed a new AccessType that would apply for things that Fortran calls inquire/inquiry e.g. lbound(ref), size(ref, 2), ..., I would keep this separate and call these "ref" AccessType INQUIRE.

[hiker]

I don't like SYMBOLIC, as any other reference is also symbolic.

I could live with STATIC and COMPILE_TIME but I don't know if they are descriptive enough (and it is similar to some of the symbol interfaces which can make it confusing).

Why don't we simply call them: CALL / CALLED

Note that before we discussed a new AccessType that would apply for things that Fortran calls inquire/inquiry e.g. lbound(ref), size(ref, 2), ..., I would keep this separate and call these "ref" AccessType INQUIRE.

I like, CALL or CALLED, too. And the idea of AccessType.INQUIRE is great, too. Probably better than the current solution of a flag (since then after all we still don't know what exactly a read access indicates, while then we can distinguish that).

Given that we are discussing access modes: while I am aware that I have added it, I wonder if we should keep READINC as access pattern. It seems to be very LFRic-specific? From a dependency point of view ... do we even need READWRITE, could that just become two accesses, one read, one write? OK, that's out of scope ;)

[arporter]

I think the runner had hit trouble so I've restarted it.

[arporter]

The compilation tests failed because my fix to compilation of nemo/eg6 revealed that the new 'generic' extraction lib was not being cleaned properly (and thus we had a .mod file from gfortran that nvfortran then wouldn't accept). I hope I've fixed this and have restarted the integration tests.

[sergisiso]

Thanks for all the clean up @arporter , the PR is almost ready but the compilation test is still failing, and I made some very small comments.

[arporter]

Finally got the compilation test fixed. I think the original error in the Makefile meant we never attempted to recompile nemo/eg6 with nvfortran (because of files left over from the gnu build) and, once I fixed that, it revealed that we weren't setting the compiler flags correctly.

This should be ready for another look now.

[sergisiso]

Fantastic, all tests are green now, this is approved for merging. Good job @arporter