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

[Ian Lance Taylor]

Tobias Burnus <burnus@net-b.de> writes:

> Would it? How does the compiler know that between "call
> SYNC_calling_proc()" the value of "coarray" could change? Hmm,
> seemingly, that's indeed the case, looking at the optimized dump of
> the example above:

The C99 restrict qualifier doesn't mean that some random function can
change the memory to which the pointer points; it means that assignments
through pointer 1 can't change the memory to which pointer 2 points.
That is, restrict is all about whether one pointer can affect another;
it doesn't say anything about functions, and in general a call to a
function can change any memory pointed to by any pointer.


> Well, then I have a different question: How can one tell the middle
> end to optimize the "if (...)" away in the following case? Seemingly
> having an "integer(kind=4) & restrict non_aliasing_var" does not seem
> to be sufficient to do so:
>
>    subroutine sub(non_aliasing_var)
>      interface
>        subroutine some_function()
>        end subroutine some_function
>      end interface
>
>      integer :: non_aliasing_var
>      non_aliasing_var = 5
>      call some_function()
>      if (non_aliasing_var /= 5) call foobar_()
>    end subroutine sub
>
> That's an optimization, which other compiles do - such as NAG or
> PathScale/Open64/sunf95.

>From a C perspective, the trick here is to know that the address
"non_aliasing_var" does not escape the current function, and that
therefore it can not be changed by a function call.  gcc already knows
that local variables whose address is not taken do not escape the
current function.  I don't know how to express the above code in C; is
there something in there which makes the compiler think that the code is
taking the address of non_aliasing_var?  If not, this should already
work.  If so, what is it?  I.e., what does this code look like in C?

Ian