(Towards #3060) intrinsic return types #3119

LonelyCat124 · 2025-09-02T09:57:02Z

I'm putting this up early so if anyone has time to have a quick look at the implementation before I go too far down the rabbit hole with how I'm implementing the return type and tests.

I have added two more members to the IAttr namedtuple, return_type and reference_accesses, which can either be a Callable or specific value (depending on whats required).

To get the return_type of an IntrinsicCall, my plan is to do something like:

def return_type(self):
    if isinstance(self.intrinsic.return_type, Callable):
        try:
            return self.intrinsic.return_type(self)
         except:
             # The idea here is to handle all of the "bad input cases", e.g. if we have an Unresolved or UnsupportedType in the input
             # I'd rather have a except here than handle it in every single return_type callable.
             return UnresolvedType()
    # If its not a callable we just return the value.
    return self.intrinsic.return_type

The return type implementations are started - there are 3 helper functions at the moment (for cases I expect to be used a lot), e.g. _get_first_argument_type, wheras other's have their own lambda (for example see AINT).

I'm unsure how much to avoid code duplication here, for example AINT and ANINT have the same lambda for their return_type, so I'm not sure whether its worth moving this out (and whether the result should be a lambda or function) every time I have any 2 intrinsic calls with the same return type? Feedback on this specific question would be appreciated as early as possible (probably one for @arporter to answer perhaps).

To test the return types, my plan was to have standalone test for every "helper" function (or even helper lambda later).
I was then planning to create a parametrize test for all other intrinsics who have their own specific lambda. My one concern is this parametrize would become very large - again feedback/thoughts on this approach would be helpful. You can see an initial versoin of how this parametrize might look at intrinsic_call_test::650.

NB. This is dependent on #3110 and I think I will rebase onto that branch for now so I can have passing tests.

LonelyCat124 · 2025-09-02T10:10:39Z

One other coding style question - are we happy with statements like:

    return ScalarType(ScalarType.Intrinsic.REAL,
                      (node.arguments[node.argument_names.index("kind")]
                       if "kind" not in node.argument_names else
                       node.arguments[0].datatype.precision))

Or would you prefer to pull out the if statement? (This was required when this was a lambda, but its turning into a function as its getting a lot of reuse so I'm happy to rewrite it if it is preferred).

LonelyCat124 · 2025-09-02T10:25:19Z

Also one thing to note is PSyclone appears to support more IntrinsicCall than are created by Fparser - e.g. BESSEL_ functions get created as ArrayReferences - I'm not sure if this will be resolved by #3041 .

Also a question for @sergisiso - can you always refer to arguments with their names? I see for example CSHIFT is defined as
RESULT = CSHIFT(ARRAY, SHIFT [, DIM]), but could you do:
RESULT = CSHIFT(shift=3, ARRAY=array)?

LonelyCat124 · 2025-09-02T14:45:00Z

I would also say - there are some cases of reusing precision througout this code. I'm not sure if this is a good idea with the new "precision can be DataNodes" - if not then the review might need to request me to fix that by copying if they're a DataNode. This probably in some cases means some significant rewrites, but I'll wait for the review (I think that datatype.copy might also have this issue?).

LonelyCat124 · 2025-09-02T15:43:40Z

I applied the black formatter to these files as well - I couldn't work out how to make formatting happy myself for a couple of the lambdas so I had to make black do it for me.

src/psyclone/psyir/nodes/intrinsic_call.py

arporter · 2025-09-03T09:15:04Z

One other coding style question - are we happy with statements like:
    return ScalarType(ScalarType.Intrinsic.REAL,
                      (node.arguments[node.argument_names.index("kind")]
                       if "kind" not in node.argument_names else
                       node.arguments[0].datatype.precision)) 
Or would you prefer to pull out the if statement? (This was required when this was a lambda, but its turning into a function as its getting a lot of reuse so I'm happy to rewrite it if it is preferred).

I think I'd prefer a separate if for this - it's quite hard to parse :-)

arporter · 2025-09-03T09:16:22Z

To get the return_type of an IntrinsicCall, my plan is to do something like:

def return_type(self):
    if isinstance(self.intrinsic.return_type, Callable):
        try:
            return self.intrinsic.return_type(self)
         except:
             # The idea here is to handle all of the "bad input cases", e.g. if we have an Unresolved or UnsupportedType in the input
             # I'd rather have a except here than handle it in every single return_type callable.
             return UnresolvedType()
    # If its not a callable we just return the value.
    return self.intrinsic.return_type

I'm a bit confused by the check on whether it is Callable. Could we avoid this by always having a lambda or am I missing something?

arporter · 2025-09-03T09:17:24Z

Thanks Aidan, I think it's looking mostly as I'd expect although, as commented above, I was anticipating always having a Callable - whether a lambda or a separate routine if it's complicated enough.

EDIT: scrub that - I was getting confused between the definition of an IntrinsicCall and an Intrinsic. I think what you're suggesting is fine actually.

LonelyCat124 · 2025-09-03T09:30:55Z

Thanks Aidan, I think it's looking mostly as I'd expect although, as commented above, I was anticipating always having a Callable - whether a lambda or a separate routine if it's complicated enough.

EDIT: scrub that - I was getting confused between the definition of an IntrinsicCall and an Intrinsic. I think what you're suggesting is fine actually.

I could always have a lambda - it just felt overkill for cases where the return type is just an INTEGER_TYPE - I'll finish implementing things as they are now and at review time if the datatype of the IntrinsicCall routine is a bit of a mess we can re-evaluate.

LonelyCat124 · 2025-09-03T14:49:57Z

I will say I semi-lost the will to carry on for specifically THIS_IMAGE - there are no GNU docs for it and I'm not sure our current version is correct anyway so I just gave up and made it UnresolvedType().

I'll clean up the remaining test suite issues before I have "finished" return_type and probably it would be good to have a closer look before I move on to implementing reference_accesses.

codecov · 2025-09-03T15:19:05Z

Codecov Report

❌ Patch coverage is 99.48718% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 99.95%. Comparing base (ee25f8a) to head (2c7c55f).

Files with missing lines	Patch %	Lines
src/psyclone/psyir/tools/type_info_computation.py	96.77%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3119      +/-   ##
==========================================
- Coverage   99.95%   99.95%   -0.01%     
==========================================
  Files         376      377       +1     
  Lines       53485    53642     +157     
==========================================
+ Hits        53463    53619     +156     
- Misses         22       23       +1

☔ 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.

LonelyCat124 · 2025-09-03T17:19:54Z

I fixed the remaining failing test and added the keywords for IAttr.
@arporter @sergisiso if either of you have time for a quick look through how I've implemented the return type functiosn and have any (specific) feedback it would be appreciated, as I'll then apply that when I look at reference_accesses as well.
I think we don't need to have a detailed overall review yet (including if the review wants to check I've not made mistakes), as that can wait until later.

LonelyCat124 · 2025-09-04T08:53:04Z

Fixed up the remaining coverage I can do with fortran_reader now - the remaining coverage is uncoveted as PSyclone can only made CodeBlock[StructureAccess] from the inputs.

LonelyCat124 · 2025-09-08T09:10:01Z

@arporter @sergisiso ready for a look now - Andy suggested doing reference accesses as its own PR separately.

There is coverage missing, but PSyclone/fparser doesn't support the inputs that could result in those - I want to leave the correct results in the code for when we do, but I'll leave it to the reviewer to decide.

Edit: Note that this PR incorporates the kind stuff from #3110 - so ignore anything that looks like it comes from changes to kinds.

Edit2: The other thing I'm unsure about for both this PR and the following PR is if we have optional arguments declared on an IntrinsicCall do they HAVE to be named in Fortran? I.e. is only integer(x, kind=wp) legal or can you just do integer(x, wp)?

LonelyCat124 · 2025-09-09T12:02:07Z

Also one note - I think TEAM_IMAGE is a typo/made up intrinsic we have? I think it should be TEAM_NUMBER (https://gcc.gnu.org/onlinedocs/gfortran/TEAM_005fNUMBER.html). If so, then let me know and I'll fix its name at least - I'll leave it to the reviewer as to whether we want return_type (and later reference_Accesses) for it.

LonelyCat124 · 2025-09-11T08:22:43Z

One note - this probably needs a todo w.r.t #2302 - I am rewriting the reference_accesses code to handle that, but this does not handle unexpected naming of arguments (that would cause IntrinsicCall.create to fail).

arporter

I realised that it's a bit early to review this as it's branched off the PR that makes precision a DataNode. Therefore, I've only done a limited look, mainly focused on intrinsic_call.py (once I realised about the branching).
I like the way it's going and thanks for adding the keywords to the arguments to the many IAttr constructors. Mainly it's the usual request for comments plus it would be really helpful to write down the rules that are implemented by the various help methods - if you could do that for all of them (in their docstrings) then that would be great. I think there's also some scope to reduce duplication.

examples/psyir/create_structure_types.py

src/psyclone/core/access_sequence.py

src/psyclone/core/signature.py

src/psyclone/domain/common/transformations/kernel_module_inline_trans.py

src/psyclone/tests/domain/common/transformations/kernel_module_inline_trans_test.py

src/psyclone/psyir/nodes/intrinsic_call.py

…3060_intrinsic_types

LonelyCat124 · 2026-01-06T16:29:08Z

@arporter Should ready for another look now.

src/psyclone/psyir/nodes/intrinsic_call.py

arporter

Nice. Thanks Aidan. Very close now. Just a bit more tidying and comments and I think there's some dead code that can be removed.
I'll fire off the integration tests.

src/psyclone/psyir/nodes/intrinsic_call.py

src/psyclone/psyir/nodes/operation.py

arporter · 2026-01-08T13:42:05Z

src/psyclone/psyir/nodes/operation.py

-                ScalarType.Intrinsic.INTEGER,
-                ScalarType.Intrinsic.REAL):
+        try:
+            return compute_scalar_type(argtypes)


Now that you've added this new method (compute_scalar_type) I think you could probably just inline the content of this method (get_result_scalar_type) at the one location (L452) where it is called.

In doing this, you'll also need to tighten-up the code a little as it's currently possible (at least theoretically) for it to return None (if none of the argument types are INTEGER or REAL).

Its not currently possible for it to return None since compute_scalar_type always falls through to raise a TypeError if it fails.

Not inlining - discussed on teams.

There is still the issue of the return value - pylint can't tell that it's not possible for it to return None and complains:

psyir/nodes/operation.py:323:4: R1710: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)

Is it possible to re-write the code so that it first finds the unsupported type and then raises the error:

actual_types = set(atype.intrinsic for atype in argtypes) actual_types -= set(ScalarType.Intrinsic.INTEGER, ScalarType.Intrinsic.REAL) raise ...list(actual_types)[0]...

src/psyclone/psyir/tools/type_info_computation.py

src/psyclone/tests/psyir/nodes/intrinsic_call_test.py

src/psyclone/tests/psyir/transformations/intrinsics/sign2code_trans_test.py

src/psyclone/tests/psyir/tools/type_info_computation_test.py

LonelyCat124 · 2026-01-09T13:15:01Z

@arporter Hopefully I got everything, should be back to you now.

…3060_intrinsic_types

LonelyCat124 · 2026-01-12T10:01:07Z

@arporter I think I got the missing parts now.

arporter

Thanks Aidan - very, very close now.
There's one bit of outstanding refactoring to reduce duplication (return type is array of rank one less than input or a scalar if that's a rank-1 array). If you dig into all previous comments you should find where I point these cases out (although there may be others I don't point out.)
There's a little bit of refactoring to make pylint happy.
There's also one line that CodeCov is saying isn't covered.
Happily the ITs were all green so I won't run them this time around.

src/psyclone/psyir/nodes/intrinsic_call.py

arporter · 2026-01-09T21:28:33Z

src/psyclone/psyir/nodes/intrinsic_call.py

+        # at compile time. It will have one fewer dimension than the
+        # input.
+        arg = node.argument_by_name(array_arg_name)
+        shape = arg.datatype.shape


I think this is worth doing. Perhaps:

def _type_of_arg_with_rank_minus_one(arg, scalar_type) -> Union[ScalarType, ArrayType]: ''' TODO ''' shape = arg.shape if len(shape) == 1: return scalar_type new_shape = [ArrayType.Extent.DEFERRED] * (len(shape) - 1) return ArrayType(scalar_type, new_shape)

arporter · 2026-01-12T16:05:01Z

src/psyclone/psyir/nodes/intrinsic_call.py

+        # at compile time. It will have one fewer dimension than the
+        # input.
+        arg = node.argument_by_name(array_arg_name)
+        shape = arg.datatype.shape


This one is still outstanding?

arporter · 2026-01-12T16:08:44Z

src/psyclone/tests/psyir/transformations/intrinsics/sign2code_trans_test.py

      ztmp1 = 0.0
-      ! Can't handle because we don't know the type of MAX or ABS
-      ztmp1 = SIGN( MAX(ABS(ztmp1),1.E-6_wp), ztmp1 )
+      ! Can't handle because MAXVAL returns an array.


I think you have it working? MAXVAL returns a scalar here?

arporter · 2026-01-12T16:26:39Z

src/psyclone/psyir/nodes/operation.py

-                ScalarType.Intrinsic.INTEGER,
-                ScalarType.Intrinsic.REAL):
+        try:
+            return compute_scalar_type(argtypes)


There is still the issue of the return value - pylint can't tell that it's not possible for it to return None and complains:

psyir/nodes/operation.py:323:4: R1710: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)

Is it possible to re-write the code so that it first finds the unsupported type and then raises the error:

actual_types = set(atype.intrinsic for atype in argtypes) actual_types -= set(ScalarType.Intrinsic.INTEGER, ScalarType.Intrinsic.REAL) raise ...list(actual_types)[0]...

LonelyCat124 force-pushed the 3060_intrinsic_types branch from 5911f97 to 9f0799f Compare September 2, 2025 15:43

arporter reviewed Sep 3, 2025

View reviewed changes

src/psyclone/psyir/nodes/intrinsic_call.py Outdated Show resolved Hide resolved

arporter reviewed Sep 3, 2025

View reviewed changes

src/psyclone/psyir/nodes/intrinsic_call.py Outdated Show resolved Hide resolved

arporter reviewed Sep 3, 2025

View reviewed changes

src/psyclone/psyir/nodes/intrinsic_call.py Outdated Show resolved Hide resolved

This was referenced Sep 4, 2025

Function Calls vs ArrayAccessors vs Type Constructors #2823

Closed

(Closes #3087) Handle expressions in the kind attribute of a declaration #3110

Merged

LonelyCat124 marked this pull request as ready for review September 8, 2025 09:02

LonelyCat124 added the ready for review label Sep 8, 2025

LonelyCat124 requested a review from sergisiso September 8, 2025 09:02

LonelyCat124 mentioned this pull request Sep 8, 2025

(Closes #3060) reference accesses for intrinsicCall #3125

Draft

LonelyCat124 changed the title ~~(Closes #3060) intrinsic return types and reference accesses~~ (Towards #3060) intrinsic return types Sep 8, 2025

arporter added under review and removed ready for review labels Sep 10, 2025

arporter requested changes Sep 11, 2025

View reviewed changes

arporter removed the under review label Sep 11, 2025

LonelyCat124 added 5 commits January 5, 2026 11:01

Merge branch 'master' into 3060_intrinsic_types

aaef92d

Merge branch '3060_intrinsic_types' of github.com:stfc/PSyclone into …

d79f0d4

…3060_intrinsic_types

Moved type info computation to its own file and added tests

3155d77

final changes for review

7d50ff5

Missing coverage

b43e9dc

LonelyCat124 added ready for review and removed reviewed with actions labels Jan 6, 2026

LonelyCat124 requested a review from arporter January 6, 2026 16:29

Merge branch 'master' into 3060_intrinsic_types

36e6113

arporter reviewed Jan 8, 2026

View reviewed changes

src/psyclone/psyir/nodes/intrinsic_call.py Show resolved Hide resolved

arporter added the under review label Jan 8, 2026

arporter requested changes Jan 8, 2026

View reviewed changes

arporter temporarily deployed to integration January 8, 2026 16:16 — with GitHub Actions Inactive

arporter added reviewed with actions and removed ready for review under review labels Jan 8, 2026

Changes for review

5631a31

LonelyCat124 requested a review from arporter January 9, 2026 13:14

LonelyCat124 added ready for review and removed reviewed with actions labels Jan 9, 2026

Merge branch '3060_intrinsic_types' of github.com:stfc/PSyclone into …

92b03e5

…3060_intrinsic_types

arporter added under review and removed ready for review labels Jan 9, 2026

Updates

2c7c55f

arporter requested changes Jan 12, 2026

View reviewed changes

arporter added reviewed with actions and removed under review labels Jan 12, 2026

(Towards #3060) intrinsic return types #3119

Are you sure you want to change the base?

(Towards #3060) intrinsic return types #3119

Conversation

LonelyCat124 commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LonelyCat124 commented Sep 2, 2025

Uh oh!

LonelyCat124 commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LonelyCat124 commented Sep 2, 2025

Uh oh!

LonelyCat124 commented Sep 2, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

arporter commented Sep 3, 2025

Uh oh!

arporter commented Sep 3, 2025

Uh oh!

arporter commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LonelyCat124 commented Sep 3, 2025

Uh oh!

LonelyCat124 commented Sep 3, 2025

Uh oh!

codecov bot commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

LonelyCat124 commented Sep 3, 2025

Uh oh!

LonelyCat124 commented Sep 4, 2025

Uh oh!

LonelyCat124 commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LonelyCat124 commented Sep 9, 2025

Uh oh!

LonelyCat124 commented Sep 11, 2025

Uh oh!

arporter left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

LonelyCat124 commented Jan 6, 2026

Uh oh!

Uh oh!

arporter left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

LonelyCat124 commented Sep 2, 2025 •

edited

Loading

LonelyCat124 commented Sep 2, 2025 •

edited

Loading

arporter commented Sep 3, 2025 •

edited

Loading

codecov bot commented Sep 3, 2025 •

edited

Loading

LonelyCat124 commented Sep 8, 2025 •

edited

Loading