Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, Jul 14, 2011 at 12:29 PM, Tobias Burnus <burnus@net-b.de> wrote:
> On 07/14/2011 11:21 AM, Richard Guenther wrote:
>>
>> That Fortran passes everything by reference is really really not helping
>> optimizers.
>
> I think it also does not harm optimizers. The problem is just that
> optimizers are not tuned for it - but for C with later (C99?) attached
> qualifiers.
>
> Whether one has
> ?int func(int arg) {
> ? ?do_something_with_arg
> ? ?return arg;
> ?}
> or
> ?subroutine func(arg) ?! arg passed by reference
> ? ? integer :: arg
>
> shouldn't make any difference for optimizers. The value can only change by
> either directly modifying "arg" or by calling a procedure with it as
> explicit actual argument, which modifies it.
>
> In Fortran, any tricks like modifying "arg" via a global variable (which
> shares the memory location with "arg") are invalid. It is not even allowed
> to read the value of the global variable (having the same memory address as
> "arg"), if the value of "arg" is modified in "func" - not even before it is
> modified.
>
> If one wants to play those tricks, "arg" needs to have at least the TARGET
> attribute (i.e. some pointer may point to it) - or even the POINTER
> attribute, for which nearly anything goes.
>
> Some of the restrictions are compile-time checkable, i.e. if you try to pass
> a non-target, non-pointer variable as actual argument to a pointer-dummy
> argument, you will get a compile-time error.
>
> For others, it's the users responsibility. For instance, you may pass a
> non-TARGET variable to a function taking a TARGET as dummy argument, but as
> soon as that function returns, all pointers to the dummy become undefined.
>
> The advantage of Fortran is that it not only applies to basic types like
> "int" but also to character strings, arrays - and to "allocatables".
> Allocatables have to be allocated before one can use them, allowing one to
> change the array size or (for deferred-length strings) the string length.
> Still, they share the same semantics, i.e. no aliasing unless there is
> TARGET or (for non-ALLOCATABLEs) a POINTER attribute.
>
> (Side remark: allocatables [unless SAVE, i.e. in static memory] are
> automatically freed, when one leaves their "scoping unit", e.g. for a
> variable local to a function, when one leaves that function. That's
> Fortran's way of garbage collection. If one does not want it, one has to use
> pointers.)
>
> In that sense, the lack of a qualifier in C, which matches Fortran, is
> "really really not helping optimizers". ;-)

Sure ;)  What the middle-end currently lacks is explicit tracking of what
escapes through a function return as opposed to what escapes somewhere
else.  Once that is implemented a flag on the PARM_DECL that tells
it to use Fortran dummy argument rules is easy to implement (but we
have issues when that dummy argument is an array descriptor and
the dummy argument rules also apply to the actual array data - as
opposed to, I presume, a dummy argument of fortran aggregate type
with a pointer member).

It's on my list to solve that function-return-escape thing, but as usual
my list of things to implement is rather large ;)

For the record, the current way of using C restrict works reasonably
well and I don't think we will gain very much in real-world performance
if not using it (though it might be cleaner to not piggy-back on the
odd C restrict semantics).

Richard.