Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Function Calls vs ArrayAccessors vs Type Constructors #2823

Open
sergisiso opened this issue Dec 9, 2024 · 0 comments
Open

Function Calls vs ArrayAccessors vs Type Constructors #2823

sergisiso opened this issue Dec 9, 2024 · 0 comments

Comments

@sergisiso
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant