(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 (2307ac7) to head (ade8c70).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2825   +/-   ##
=======================================
  Coverage   99.88%   99.89%           
=======================================
  Files         359      359           
  Lines       50833    50919   +86     
=======================================
+ Hits        50777    50864   +87     
+ 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]

Sphinx link check failed on the NEMO homepage with a timeout.

[arporter]

This is ready for another look now. I've kept the COMPILE_TIME access for now but am happy to rename it next time around.

[arporter]

Also towards #1792.

[arporter]

The integration test failure was a small thing in SymbolTable that I'd already fixed in another PR so I've brought those changes into this one. I'll re-launch the integration tests if the CI is happy.