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 5:31 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Thu, 14 Jul 2011, Richard Guenther wrote:
>
>> 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).
>
> And the latter is also why such a flag/attribute needs to be ultimately
> placed on the type, so that we can form pointers to such parm_decls (or
> even members of array descriptors) without loosing the special guarantees,
> ala "not clobbered by calls". ?That or flags on the MEM_REF (which
> magically needs to be set then, most probably again, by tracking such flag
> from the PARM_DECL, through types to the MEM_REF).
>
>> 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
>
> Did you really want to say this? ?Because I'm very sure we actually loose
> very much in real-world performance if we wouldn't be using it (or some
> alterntive that is specified somewhat cleaner).

I meant to say if we are not using restrict but another more frontend-specific
flag as suggested.  Not if we drop restrict without replacing it with
anything else.

Richard.