[J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

Wed Dec 20 00:01:20 UTC 2023

There is a lot of vague talk about “[conceptual] global state” in this thread, and it is unhelpful.

Simple procedures cannot refer to variables that are not in the argument list. That is an optimisation opportunity – e.g. in an elemental array assignment, a simple function cannot read the variable being assigned to, so no array temp or advanced analysis is needed.

That one cannot copy the evaluation of things that depend on the image number into/outof a CHANGE TEAM construct is kind of obvious, and does not obviate the usefulness of SIMPLE nor of CHANGE TEAM. There are lots of things one cannot move across any segment boundary actually – e.g. common subexpression elimination often cannot be done across one.

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Brad Richardson via J3
Sent: Wednesday, December 20, 2023 7:37 AM
To: Steidel, Jon L <jon.l.steidel at intel.com>; General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

But we already had that for PURE procedures. What added benefit do you get from SIMPLE procedures if they can refer to global state?

On Tue, 2023-12-19 at 22:17 +0000, Steidel, Jon L wrote:

Hi Brad,

Knowing a procedure does not modify a COMMON or MODULE variable allows the compiler to hold values of COMMON and MODULE variables in registers across a call to a SIMPLE procedure, and not have to store to memory a locally modified COMMON or MODULE variable prior to the call, and reload the variable from memory upon return from the call.   

-jon

From: J3 < <mailto:j3-bounces at mailman.j3-fortran.org> j3-bounces at mailman.j3-fortran.org>On Behalf Of Brad Richardson via J3
Sent: Tuesday, December 19, 2023 5:11 PM
To: General J3 interest list < <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Cc: Brad Richardson < <mailto:everythingfunctional at protonmail.com> everythingfunctional at protonmail.com>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

This was kind of my point. Yes I understand the argument that "intrinsics are allowed to do magic that user procedures are not", but this has broader reaching implications about the semantics of the language. If calls to simple procedures can actually return different outputs with the same arguments, what was the point of adding them?

Brad

On Tue, 2023-12-19 at 20:32 +0000, Clune, Thomas L. \(GSFC-6101\) via J3 wrote:

Reuben,

I think it is the other way around.   The definition of SIMPLE is missing a bit that might be hard to define in the standard.   If so then we need a more nuanced list of SIMPLE intrinsics.

The key thing with the “bad” intrinsic procedures is that there is an implicit context that is accessed when they run.   I strongly suspect that under-the-hood, there is the equivalent of COMMON/Save in the form of some private state inside the run-time library.

This is one of the reasons I was uncomfortable with the coarray approach of not passing an object to the intrinsics.   With MPI we have a “comm” object that  controls access.    (MPI has other sins, so just defending the value of biting the bullet and accepting another argument can be a good thing in an intrinsic.)

* Tom

From:J3 < <mailto:j3-bounces at mailman.j3-fortran.org> j3-bounces at mailman.j3-fortran.org> on behalf of j3 < <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Reply-To: j3 < <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Date: Tuesday, December 19, 2023 at 2:59 PM
To: j3 < <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Cc: "Reuben D. Budiardja" < <mailto:reubendb at ornl.gov> reubendb at ornl.gov>
Subject: [BULK] Re: [J3] [EXTERNAL] Should all intrinsic functions be simple?

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

On 12/19/23 11:04, Brad Richardson via J3 wrote:

<snipped>

However, that would not

necessarily be true for all of the intrinsic functions. Take the

following example:

cur_team = get_team()

...

change team (new_team)

    cur_team = get_team()

    ...

end team

Clearly, it is intended that the two calls to get_team return different

results, so common subexpression elimination would not be valid here.

Also, conceptually, it would not be possible to implement this call in

a way that does "not contain a designator of a variable that is

accessed by use or host association" or "not contain a reference to a

variable in a common block" as it clearly must be accessing some global

state of the program.

Intrinsic functions which may be affected include:

* failed_images

* get_team

* image_index

* num_images

* stopped_images

* team_number

* this_image

I think this is conflating what a compiler may need to do with the

actual program. From the program standpoint, the example above does not

violate any of the simple-ness constraints (or any of the listed

function). So I still think they are SIMPLE.

Best,

Reuben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20231220/9bf2a69a/attachment.htm>