This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] noclobber & noescape annotations for function arguments
On Fri, 7 May 2010, Janne Blomqvist wrote:
> On Thu, May 6, 2010 at 13:39, Richard Guenther <rguenther@suse.de> wrote:
> > Other Fortran intrinsics that very often confuse optimizers are
> > the I/O ones. ?For example write (*,*) X causes us to call
> > _gfortran_st_write (&dt_parm) and _gfortran_st_write_done (&dt_parm).
> > Both clobber dt_parm (and in general what it points to). ?But
> > do they cause anything to escape?
>
> So, um, noclobber means that the argument is not written to, i.e.
> read-only? And noescape means the function does not in one way or
> another retain a pointer to the argument after returning?
Yes.
> Another thing is that we use the same transfer_XXX() calls for both
> reads and writes; hence we can't mark these functions noclobber
> (assuming my speculation about what it means is correct above). The
> transfer_XXX() functions are the ones that provide the addresses of
> the actual data to read or write.
> > ?(people keep mentioning
> > async I/O here - would that use exactly the same functions?)
>
> Currently that's the plan, yes; with AIO, dt_parm is copied to a work
> queue in heap memory, from where a thread pool then executes the IO in
> the background. For the transfer_XXX() calls, pointers to the
> arguments are stored in the work queue.
Ok, so the arguments do escape to the functions. I suppose the
caller of the AIO has to ensure it does not change the data before
the AIO has completed? Or is the data copied somewhere else?
I'm thinking of
A = 1
write A ; with AIO
A = 0
how do I ensure that 1 is written and not 0 with AIO?
Well, at least with the current I/O setup it seems to be impossible
to assert anything useful for the optimizers just depending on
the function that is called.
Richard.