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

[Michael Matz <matz at suse dot de>]

Hi,

On Sat, 16 Jul 2011, Richard Guenther wrote:

> > 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.

I see.  Well, whatever frontend specific flag we want to invent, it always 
will be the case that the information conveyed by it somehow has to be 
represented for the middle end, and that it must survive pointer-taking 
and pointer-adjustment.  It can survive these operations either by
 1) being placed directly on the memory accesses right from the start in 
    the frontend
 2) creating a tracking device looking backward from mem accesses through 
    pointer-take/modify until we hit a so marked entity (probably a DECL)
 3) modifying the type of such marked entity (which ripples down to the 
    mem access automatically then)

Currently we have a mix of (3) (to determine the speciality of some 
pointers at all) and (2) (to determine which particular set of the 
partition of all such special pointers a certain pointer belongs to).  I 
don't really see how this would change much in structure however we define 
the frontend flags.


Ciao,
Michael.