On Thu, Jul 14, 2011 at 5:31 PM, Michael Matz <m...@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.
