public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tobias.burnus@physik.fu-berlin.de>
To: Alessandro Fanfarillo <fanfarillo.gcc@gmail.com>
Cc: gfortran <fortran@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	opencoarrays@googlegroups.com
Subject: Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment
Date: Tue, 08 Dec 2015 10:01:00 -0000	[thread overview]
Message-ID: <20151208100109.GA23573@physik.fu-berlin.de> (raw)
In-Reply-To: <CAHqFgjXR5+y_=XXPTAxzjE0P2qq2NJiABnHd03zX-VfNfjuuGg@mail.gmail.com>

Dear Alessandro, dear all,

On Mon, Dec 07, 2015 at 03:48:17PM +0100, Alessandro Fanfarillo wrote:
> Your patch fixes the issues. In attachment patch, test case and changelog.

Regarding the ChangeLog: Please include the added lines, only, and not the
change as patch. gcc/testsuite/ChangeLog changes too often such that a patch
won't apply.


Regarding the patch, I wonder where the memory synchronization makes sense
and where it is not required. (cf. also my email to Matthew in this thread,
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00828.html)


I think it should be after all image control statements (8.5.1 in
http://j3-fortran.org/doc/year/15/15-007r2.pdf):
SYNC ALL, SYNC IMAGES, SYNC MEMORY, ALLOCATE, DEALLOCATE,
CRITICAL ... END CRITICAL, EVENT POST, EVENT WAIT, LOCK, UNLOCK,
MOVE_ALLOC.

Thus:
- SYNC ..., ALLOCATE/DEALLOCATE: I think those are all handled by the
  current patch
- MOVE_ALLOC: This one should be handled via the internal (de)allocate
  handling (please check!)
- EVENT WAIT, CRITICAL and LOCK: Obtaining a lock or receiving an event
  implies that quite likely some other process has changed something
  before. For those, the assembler statement really has to be added.
- EVENT POST, UNLOCK and END CRITICAL: While those are image control
  statements, I do not see how a remote image could modify a value in
  a well defined way, which is guaranteed to be available after that
  statement - but might not yet be available already at the previous
  segment (i.e. the previous image control statement).

Hence: I think you should update the patch to also handle 
EVENT WAIT, CRITICAL and LOCK - and to check MOVE_ALLOC.



Additionally, we need to handle the alias issue of:
  var = 5
  var[this_image()] = 42
  tmp = var

Both _gfortran_caf_send and _gfortran_caf_sendget can modify the
value of a variable; thus, calling the assembler after the function
makes sense.


However, _gfortran_caf_get does not modify the associated variable;
adding the assembler statement *after* _gfortran_caf_get. The
question is, however, whether one needs to take care of 'flushing'
the variable before the _gfortran_caf_get:
   var = 7
   ...
   var = 5
   tmp = var[this_image()]
   result = var + tmp
Here, one needs to prevent the compiler of keeping "5" only in a
register or moving "var = 5" after the _gfortran_caf_get call.


Thus, you have to move the assembler statement before the library
call in _gfortran_caf_get - and add another one at the beginning
of _gfortran_caf_sendget.

(For send/get, might might come up with something better than
""::"memory", but for now, it should do.)

Cheers,

Tobias

  reply	other threads:[~2015-12-08 10:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-06 21:02 Alessandro Fanfarillo
2015-12-07  7:20 ` Tobias Burnus
2015-12-07  9:16   ` Alessandro Fanfarillo
2015-12-07 10:06   ` Tobias Burnus
2015-12-07 14:09     ` Matthew Wahab
2015-12-08  9:26       ` Tobias Burnus
2015-12-09 14:47         ` Matthew Wahab
2015-12-07 14:48     ` Alessandro Fanfarillo
2015-12-08 10:01       ` Tobias Burnus [this message]
2015-12-08 14:21         ` Alessandro Fanfarillo
2015-12-09  7:23           ` Tobias Burnus
2015-12-09 16:08             ` Alessandro Fanfarillo
2015-12-09 22:16               ` Tobias Burnus
2015-12-10  8:44                 ` Alessandro Fanfarillo
     [not found]                   ` <20151210090345.GB6991@physik.fu-berlin.de>
     [not found]                     ` <CAHqFgjVhx6pcVFEaCT8=9P+vkR=SP-mohZwr+B315N0_41OtKA@mail.gmail.com>
2015-12-14 19:14                       ` Tobias Burnus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151208100109.GA23573@physik.fu-berlin.de \
    --to=tobias.burnus@physik.fu-berlin.de \
    --cc=fanfarillo.gcc@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=opencoarrays@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).