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

Wed Dec 20 13:48:26 UTC 2023

> Simple procedures cannot refer to variables that are not in the argument list.

This is exactly the kind of simple and intuitive way I like to think about SIMPLE procedures. However, the current team is "a thing that varies" (albeit not declared as a variable anywhere), and it is clearly referred to in the procedures I listed (assuming the team and team_number arguments are not present).

I would have thought the implication of "cannot refer to variables that are not in the argument list" is that a call to such a procedure with the same argument values returns exactly the same result values, but the procedures I listed violate that expectation. I believe that is confusing and thus those procedures should not be listed as SIMPLE, just PURE. If all the vendors can say "we totally wouldn't have expected 'cannot refer to variables that are not in the argument list' to imply 'a call to such a procedure with the same argument values returns exactly the same result value'" I'll concede it was just me expecting too much and leave it at that. But I will point out that Wikipedia has the following to say on the subject in a general programming sense: https://en.wikipedia.org/wiki/Pure_function

> the function [return values](https://en.wikipedia.org/wiki/Return_statement) are [identical](https://en.wikipedia.org/wiki/Relational_operator#Location_equality_vs._content_equality) for identical [arguments](https://en.wikipedia.org/wiki/Argument_of_a_function) (no variation with local [static variables](https://en.wikipedia.org/wiki/Static_variable), [non-local variables](https://en.wikipedia.org/wiki/Non-local_variable), mutable [reference arguments](https://en.wikipedia.org/wiki/Value_type_and_reference_type) or [input streams](https://en.wikipedia.org/wiki/Input/output))

Regards,
Brad

On Wed, 2023-12-20 at 09:01 +0900, Malcolm Cohen via J3 wrote:

> 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 <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 <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?
>>
>> 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 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
>>> Reply-To: j3 <j3 at mailman.j3-fortran.org>
>>> Date: Tuesday, December 19, 2023 at 2:59 PM
>>> To: j3 <j3 at mailman.j3-fortran.org>
>>> Cc: "Reuben D. Budiardja" <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/4e029194/attachment-0001.htm>