#1312 ScalarArray code generation

[mo-alistairp]

Adding code generation for ScalarArrays (towards #1312 ). The metadata support was added in #2173.

[arporter]

This isn't true I'm afraid - they will need to be added to a data region. However, you could leave this as a TODO as I'm not sure we're ever going to need data regions.

[mo-alistairp]

Thanks for that - it's currently a very rough draft so some of the comments are currently just borrowed from other functions. But, I will definitely note that down!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.90%. Comparing base (5614b30) to head (33caeac).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3101   +/-   ##
=======================================
  Coverage   99.90%   99.90%           
=======================================
  Files         374      374           
  Lines       52358    52368   +10     
=======================================
+ Hits        52307    52317   +10     
  Misses         51       51           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mo-alistairp]

This still isn't working as intended, but is getting closer to correct. As an example, the code gen is now adding the scalar arrays to the generated code, alongside the arrays containing their dimensions. However, it is not adding these dimensions to the generated code (e.g., no dimensions(...) mention). It is also assigning the field as intent(in) right now, which it shouldn't do either.

Furthermore, the stub_gen test is failing because we are currently adding the dimensions array to the psyir layer as an ArgumentInteraface which isn't there as an argument at the call. Need to find a way around this. I'm wondering if we need a dimensions array at all but I'll have to investigate that further.

[mo-alistairp]

This is definitely a step in the right direction. I have managed to add ArrayReferences to the dimensions array. The current code generation is creating the following -

integer(kind=i_def), intent(inout) :: integer_array
integer(kind=i_def), dimension(4), intent(in) :: dims_integer_array
integer(kind=i_def), dimension(dims_integer_array(1),dims_integer_array(2),dims_integer_array(3),dims_integer_array(4)), intent(in) :: integer_arraytemp

There are two problems -

• the _array symbol is being added before this code, seemingly not even as a scalar, rather than a ScalarArray. This is why I was previously having trouble getting it to display the dimensions - because it wasn't an array! Currently I am side-stepping this problem by creating a new symbol (ending with temp), but this needs an actual fix
• the dims_array symbol is producing an error as it is not a kernel argument at present, but has an ArgumentInterface - e.g., psyclone.errors.InternalError: PSyclone internal error: ("Symbol dims_rscalar_array_2: DataSymbol<Array<Scalar<INTEGER, Reference[name:'i_def']>, shape=[2]>, Argument(Access.READ)> is not listed as a kernel argument and yet has an ArgumentInterface interface.",).

I need to find out where the symbol is first added to the tree - I think doing so might allow me to fix both issues.

[mo-alistairp]

The current failure is a bit strange, I haven't touched testkern_type explicitly so I'm a bit confused why it's got the wrong number of arguments all of a sudden. I'll keep investigating - I could always reverse my changes which caused the error to see if that fixes it. Irrespectively, I think it makes sense to have a normal scalar value in the test to check that it's not being affected by ScalarArrays being there.

[mo-alistairp]

This is now generating code and the stub for my written tests. The code gen looks sensible, the stub gen needs more work. I haven't managed to fix the error which is prematurely failing the tests.

[mo-alistairp]

The body of the code gen and stub gen looks correct - the only thing to fix is the number of variables appearing in the call of the code gen and the subroutine definition of the stub generation