From owner-sc22wg5@open-std.org Thu Jan 22 20:52:42 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id D9882CA5FED; Thu, 22 Jan 2009 20:52:42 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from nspiron-2.llnl.gov (nspiron-2.llnl.gov [128.115.41.82]) by www2.open-std.org (Postfix) with ESMTP id E0810CA3432 for ; Thu, 22 Jan 2009 20:52:40 +0100 (CET) X-Attachments: None Received: from cyrus2.llnl.gov ([128.15.97.105]) by nspiron-2.llnl.gov with ESMTP; 22 Jan 2009 11:52:38 -0800 From: Aleksandar Donev Organization: LLNL To: j3@j3-fortran.org Subject: Re: (j3.2006) [MPI3 Fortran] (SC22WG5.3891) [ukfortran] =?iso-8859-1?q?MPI=09non-blocking?= transfers Date: Thu, 22 Jan 2009 11:52:38 -0800 User-Agent: KMail/1.9.4 Cc: MPI-3 Fortran working group , WG5 References: <200901221111.01710.donev1@llnl.gov> <4978CB93.2050609@cray.com> In-Reply-To: <4978CB93.2050609@cray.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901221152.38701.donev1@llnl.gov> Sender: owner-sc22wg5@open-std.org Precedence: bulk On Thursday 22 January 2009 11:40, Bill Long wrote: > The only safe thing for the > compiler to do is treat array as volatile throughout the subprogram > containing these two calls. No! For ASYNCHRONOUS, there is a restriction on the *programmer* that if array is referenced/defined, it is not currently a pending I/O affector. This is the same as for coarrays, which may make things clearer: If a coarray is defined/referenced, the compiler can fully optimize without worrying about other images, *in-between* image-control statements. The same logic applies for ASYNCHRONOUS---optimize unless you see a WAIT. Note however that some of the optimizations Nick mentioned should also be disabled for coarrays. Notably, a piece of a coarray that is *not* referenced/defined in a segment *may* indeed be referenced/defined by other images. So the optimizer must not touch those pieces, even in what would be harmless ways in a serial code. For a classic (serial) optimizer, ASYNCHRONOUS and coarrayness and threading and all of those things are essentially the same: Something else, which is not included in the classic control/data flow analysis, can store/load certain values, which are marked in some sense (via CODIMENSION/ASYNCHRONOUS/VOLATILE attribute). Do you think all coarrays are effectively VOLATILE??? If not, then the same applies to ASYNCHRONOUS variables. Aleks