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

[Brad Richardson]

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/20231219/a1259f00/attachment.htm>