-fargument-noalias-global question

[Toon Moene]

Richard Guenther wrote:

> On Sat, 3 Jan 2009, Toon Moene wrote:

>> The pointers used by the Fortran Front End to implement Fortran's argument
>> association *cannot* point to anything else than the storage of those
>> arguments, because they (those pointers) are generated by the compiler and
>> cannot point to anything else (they cannot be modified).
> 
> Ok.  I guess that would answer my request from earlier last year as if
> that includes reachable memory - not.

I am sorry about that.  The number of unread mails in my inbox from last 
year is 13635.

> The issue is with fortran
> array passing which is (simplified) done from a middle-end point of view
> as
> 
>  struct { void *data; } array1, array2;
>  array1.data = xyz;
>  array2.data = wur;
>  foo (&array1, &array2);
> 
> so - if the argument to foo aliases with nothing that doesn't help
> optimization.  We know that array1->data and arrray2->data do
> not alias - but we do _not_ know that *array1->data (*xyz) and
> *array2->data (*wur) do not alias - unless that "aliases nothing"
> extends to everything reachable from the arguments.

The point is that *inside foo* the compiler is free to assume two array 
arguments cannot overlap.  If, outside foo, they do, that's a 
programmer's error.

> I btw installed that (wrong?) patch based on the answers I got.

My apologies - see above.

>> Whether or not -fargument-noalias-anything is useful for languages other than
>> Fortran is anybody's guess (I'm betting on "none").
> 
> It needs to be useful to the middle-end at least ... which is why I am
> asking for a specification in middle-end terms.

> You shouldn't have exposed those options to outside of fortran then ...

Good point.  I got carried away when asked to document these options - 
instead, I should have insisted on internalizing them to the Fortran 
Front End.

>> Note that COMMON data in Fortran escapes by default, because it can be
>> accessible in any other compilation unit (just by including the COMMON
>> declaration).
>>
>>> int *p;
>>> void foo(int *q)
>>> {
>>>   may *q and *p alias?
>>> }
>> The canonical Fortran example is:
>>
>>       SUBROUTINE AAP(P)
>>       COMMON /NOOT/ Q
>>
>> P (which is a pointer in the backend sense of the word - it's not a Fortran
>> pointer) cannot point to the memory indicated by Q.
> 
> The C example above is different, the COMMON section would contain a
> pointer and the question was whether that pointer may point to the same
> memory as P.  Maybe that situation is not possible at all in Fortran, so
> you maybe didn't think about that ;)

Indeed.

>>> consider
>>>
>>> void bar()
>>> {
>>>   int i;
>>>   p = &i;
>>>   foo (&i);
>>> }
>>>
>>> does that call to foo invoke undefined behavior if built with
>>> -fargument-noalias-global?
>> It shouldn't, as 'int i' isn't global.  Now a more interesting question (one
> 
> Well, it is globally reachable after the assignment p = &i - which is
> the core of my question - does global memory include globally reachable
> memory?  Note that semantics too "Frontend tied" are very hard to
> implement in the middle-end.

Ah, I didn't see your example as a single compilation unit, so I 
wondered where p came from ...

Yes, this would make it fail the restrictions of Fortran, so it isn't 
covered by -fargument-noalias-global.

>> -global means it cannot point to global memory (but it assumes global memory
>> works like Fortran's COMMON).
> 
> I see.  Both are not what is currently implemented by the way.

Well, that might explain why the new flag didn't make a difference :-)

Thanks for this in-depth analysis.

-- 
Toon Moene - e-mail: toon@moene.org (*NEW*) - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html