RFA: Revamp fortran array types

[Tobias Burnus]

Am 18.08.2009 18:13, schrieb Steve Kargl:
> On Tue, Aug 18, 2009 at 05:20:02PM +0200, Richard Guenther wrote:
>   
>> On Tue, Aug 18, 2009 at 5:14 PM, Steve
>> Kargl<sgk@troutmask.apl.washington.edu> wrote:
>>     
>>> The standard prohits a programmer from aliasing
>>> the input arguments.  The standard also does not require a
>>> compiler to detect aliasing.
>>>       
In the most common case, the standard does not allow "call foo(a,a)" -
but as written before, if the effective argument is a target (as in
Michael's example - the two pointers point to the same named variable,
which has the "target" attribute.), it is valid.
That a compiler does not have to detect (invalid) aliasing is quite
fortunate - otherwise one had to insert tons of run-time checks - which
does not make sense for a language which aims at high-performance computing.

>> Doesn't that effectively make pointer and targets useless?
>>     
No - it allows the compiler to do optimizations, except when explicitly
told. I would, however, suggest to check with the standard as ever
paraphrasing of it tends to oversimplify things.

> Of course, it means a programmer needs to know what the 
> rules are for the language.

Well, a programmer should roughly know what is allowed in a language and
should use things which are allowed - (s)he does not need to know all
the fine prints about things which are allowed under very specific
circumstances. Only compiler writers should know.
I think no one - not even Richard Maine [editor of the F2003 standard] -
knows all the rules by heart; everyone needs to check the standard to
know for sure.

> Suppose, Michael's clobber
> function was in a stand-alone file (ie., not a contained
> procedure).  How can a compiler diagnose that p,p2 alias
> without incurring some runtime penalty.
>   
It can't. But if the dummy argument it a POINTER the compiler must
assume that the arguments might be (fully or partially) referring to the
same memory. I think that is the one of the main point of having a
POINTER (and the TARGET attribute).

> This goes back to the age-old argue that a Fortran program
> will run faster than an equivalent C program because a 
> Fortran can assume that array arguments in function calls 
> do not alias;

Well, in C one needs to tell the compiler explicitly that a pointer will
not alias with another pointer/variable, but if one does not use
"restrict" they may. In Fortran, it is the other way round: By default
they may not alias, but if you allow it explicitly (pointer, target)
then it is allowed. (Granted, "restrict" is a newer invention [C99].)

In the end a C and a Fortran program should have the same speed; there
are some minor points which play a large role at different optimization
levels, but at the end, there is no reason that one program should be
magically faster than the other.
Regarding the fine prints: I think Fortran has the better 'defaults' -
like restrict vs. pointer/target. Or the way expressions might be
reordered while parenthesis remain effective. Or the default handling of
complex numbers. However, if one wants to follow IEEE 754:2008, certain
Fortran-allowed optimizations cannot be done. Or on the other hand,
using -O3 -ffast-math - do you still want to honour all the parentheses?

>> Or is the scope where a compiler is not required to detect
>> aliasing somehow restricted?
>>
>> Thus for
>>
>>   p => a
>>   p2 => a
>>   p = 1
>>   p2 = 2
>>
>> the compiler is allowed to re-oder the two stores?
>>     
> I would need to go read up on the finer points of the
> properties of Fortran pointers, but I believe the answer
> may be "yes".
I would expect that the answer is "no" - even though I would not rule
out that I missed something in the standard. The point is that "p" and
"p2" are pointers and thus might access the same memory.


>   p1 => b
>   p2 => b
>   j = clobber(p1, p2)
> [...]
> integer function clobber(x,y)
>    integer, pointer, intent(in) :: x
>    integer, pointer, intent(out) :: y
>    y = 2
>
> The assignment to y has changed the intent(in) x.
>   
No it has not. For pointers, the intent applies to the memory location
and not to the value. As there is no pointer assignment in "clobber",
"x" still points at the same memory location as before.

Pointer intents were added in Fortran 2003; to quote from the standard
(this time F2003, 4.1.2.7 INTENT attribute):

C545 (R517) A nonpointer object with the INTENT (IN) attribute shall not
appear in a variable definition context (16.5.7).

C546 (R517) A pointer object with the INTENT (IN) attribute shall not
appear as
 (1) A pointer-object in a nullify-stmt,
 (2) A data-pointer-object or proc-pointer-object in a
pointer-assignment-stmt,
 (3) An allocate-object in an allocate-stmt or deallocate-stmt, or
 (4) An actual argument in a reference to a procedure if the associated
dummy argument is a pointer with the INTENT (OUT) or INTENT (INOUT)
attribute.

Tobias