Function Calls vs ArrayAccessors vs Type Constructors

[sergisiso]

When we don't have the type of a symbol, it is ambiguous what the expression below is:

subroutine test()
   use other_module
   a = myimportedysymbol(1)
end subrotuine

Currently we often default to ArrayAccessor, but this is unsafe for GPU offloading as array accessors are pure/available on the device, but this is not the case for the other 2 cases where this needs to be checked. For this reason, we have a NEMO_FUNCTIONS in utils.py which is often outdated or broken for untested branches.

In such cases we should make "myimportedysymbol" a CodeBlock, or at least a Call. This will have a significant impact on the GPU offloading performance of NEMO but I think it is necessary for getting people going with correct results and we can get it back the performance by more precise use of the "resolve_imports" functionality.

There is a similar issue in stfc/fparser#384 , but it can be resolved there or in the Fparser2Reader.

[LonelyCat124]

I guess as an issue, the following code:

subroutine test
        integer, dimension(100) :: x
        integer, dimension(100) :: y
        y = coshape(x, kind=4)
end subroutine test

creates:

FileContainer[]
    Routine[name:'test']
        0: Assignment[]
            Reference[name:'y']
            CodeBlock[[<class 'fparser.two.Fortran2003.Structure_Constructor'>]]

I guess this is an fparser issue - but we have quite a lot of IntrinsicCalls that fall through into PSyclone in unexpected ways - some of which just become ArrayReference, some of which become like the above. We should probably also fix this up and handle these as expected. I'll make an fparser issue and keep a list.

[sergisiso]

@LonelyCat124 I have "fixed" this in #3041 but I am not planning to merge it until after the release to not add any significant change so close to the end of NG-ARCH.

The "fix" is just chaning the default for ambiguous cases to funtion_call, accessors and constructors can safely be considered function calls but not the other way arround. Also we can now follow module imports, which means that we can request to retrieve the correct type for most symbols.

If that doesn't solve the CodeBlock above I would consider it a separate issue regaring the Fortran Reader for Fortran2003.Structure_Constructor

[LonelyCat124]

Ok, I think #3119 is not in a rush to have those working (we can have the additional tests that are commented out added later). There are also missing intrinsics in fparser that we should probably add at some point to match PSyclone's understanding, though we do have a few mystery ones that I think are just Intel coarray specific? Or at least don't have gnu docs.

[sergisiso]

Ok, I think #3119 is not in a rush to have those working (we can have the additional tests that are commented out added later).

Ah, I didn't know what was the context for the comment. Yeah I think that to have all intrinsics we need a fparser PR followed by PR to make sure all of them go through. But I think we can do #3041 and #3119 with the current supported intrinsics.

Sorry for the delayed review of the kinds PR, I will get back to it this week.