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
next prev parent 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).