This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -fargument-noalias-global question


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]