[patch, fortran, RFC] Separate READ from WRITE

[Tobias Burnus]

  On 10/10/2010 11:58 PM, Jerry DeLisle wrote:
> On 10/10/2010 10:23 AM, Thomas Koenig wrote:
>> this RFC patch separates reads from writes in Fortran, by establishing
>> separate transfer functions for writing, with a different spec.  For
>> now, the write functions just call the original transfer functions, with
>> the spec making all the difference.
>
> That patch seems straight forward, so I like that aspect of it.  We 
> can later consider further sepration on the library side.

I think if one separates the library part, the patch is really 
profitable - though the library part is a post-4.6 item as it will break 
the ABI - unless we add also a read version and use the generic version 
to branch to either version.

> I do not understand what these specs wW and rW mean.  How did you 
> learn about this?

That's in a way the middle-end equivalent to INTENT(IN) and to 
TARGET/POINTER vs. not-TARGET/POINTER: Namely, whether the value is 
modified (clobbered) or not and whether a pointer address can escape or 
not. This is already widely used by gfortran - but as for READ the same 
transfer function is used as for WRITE, one cannot tell the middle end 
that the value in a READ transfer is not modified.

The annotation was introduced by Richard and works like 
"__attribute__((...))"; however, the attribute has a space in the name 
("fn spec") which prevents the external, user-code usage. (The reason 
for the space is: It was a bit unclear how the syntax should be - if it 
is only internally usable, one can easily change it, if needed.)

Cf. PR 43665 for the details of "fn spec". (That PR is about using "fn 
spec" in gfortran - thus, the changelog to Thomas' patch should in my 
opinion also list that PR.)


>> This does speed up the test case from PR 31593, and should also at least
>> partially fix PR 20165.
>
> What is the difference in time with and without the patch?

That strongly depends on the test case; one tells the middle end that 
the argument does not get modified, implying that the middle end can do 
all kind of optimizations. I assume that most of the time the 
optimizations are not crucial, but for some programs it could make a 
huge difference. (However, one should, if possible, not use I/O in a hot 
loop ...)

> What about the other patches discuss in pr31593? No longer needed?

I think this patch is a bit orthogonal. If you use

do i = 1, 10
     call foo(i)  ! Or "write(*,*) i"
end do

The "i" is assumed to be potentially modified by "foo" unless its first 
argument is known to be INTENT(IN)  (or VALUE). If it is INTENT(IN) or a 
WRITE/PRINT statement (with Thomas' patch), the previous patches are not 
needed (and make things worse). The problem are procedure calls which 
have no (known) INTENT attribute - hence, a "fn spec" cannot be used* 
and thus doing something as in Tobias Schlueter's patches could still be 
useful.

Tobias

* The fact that the procedure is called within a DO loop does not help; 
for instance:
subroutine foo(i)
   if (.not. in_do_loop) ! Host associated logical variable
     i = 42
   end do
end
would be valid in DO loops. Thus, assuming that the argument is 
INTENT(IN) since it is used in a loop is wrong - leading to wrong code 
if "foo" is called with no loop variable as argument.