Discussion:
[gomp4] OpenACC wait directive
Cesar Philippidis
2014-09-23 22:29:46 UTC
Permalink
This patch adds support for the async clause in the wait directive in
fortran. It should be pretty straight forward. The fortran FE already
supports the wait directive, but the async clause was introduced to the
wait directive in OpenACC 2.0 and that was missing in gomp-4_0-branch.
Is this OK for gomp-4_0-branch? Note that this patch doesn't actually
implement the async or wait clause in the middle end yet, because that
requires additional runtime support.

Thanks,
Cesar
Ilmir Usmanov
2014-09-24 07:18:56 UTC
Permalink
Hi Cesar!

Thank you for the patch!
Post by Cesar Philippidis
This patch adds support for the async clause in the wait directive in
fortran. It should be pretty straight forward. The fortran FE already
supports the wait directive, but the async clause was introduced to the
wait directive in OpenACC 2.0 and that was missing in gomp-4_0-branch.
Yes, I've mostly focused on spec. ver. 1.0.
Post by Cesar Philippidis
Is this OK for gomp-4_0-branch?
No, it isn't. According to the spec and this presentation:
http://www.pgroup.com/lit/presentations/cea-3.pdf (See slide 1-35)
it is possible to write construction like:
!$acc wait(1) async(2)
However, your patch doesn't support this. Also, don't forget to check
whether a queue waits itself (for example, wait(1) async(1)).
In addition, it breaks current support of the directive (for example,
wait(1)).
Post by Cesar Philippidis
Note that this patch doesn't actually
implement the async or wait clause in the middle end yet, because that
requires additional runtime support.
Thanks,
Cesar
--
Ilmir.
Cesar Philippidis
2014-10-03 14:34:29 UTC
Permalink
Post by Ilmir Usmanov
Hi Cesar!
Thank you for the patch!
Post by Cesar Philippidis
This patch adds support for the async clause in the wait directive in
fortran. It should be pretty straight forward. The fortran FE already
supports the wait directive, but the async clause was introduced to the
wait directive in OpenACC 2.0 and that was missing in gomp-4_0-branch.
Yes, I've mostly focused on spec. ver. 1.0.
Post by Cesar Philippidis
Is this OK for gomp-4_0-branch?
http://www.pgroup.com/lit/presentations/cea-3.pdf (See slide 1-35)
!$acc wait(1) async(2)
However, your patch doesn't support this. Also, don't forget to check
whether a queue waits itself (for example, wait(1) async(1)).
In addition, it breaks current support of the directive (for example,
wait(1)).
Sorry for the delay. I encountered some problems with the runtime in our
internal branch, and that slowed things down a bit.

Anyway, you are correct, I broke the optional argument to wait in the
previous patch. This new patch addresses that and it also make the wait
construct conform with OpenACC 2.0. Specifically,

!$acc wait (1, 2) async (3)

should behave as ex[ected.

If you look at gfc_trans_oacc_wait_directive, you'll note that a call to
GOACC_wait is emitted for the wait directive. Since I had to add a
runtime library stub for that builtin function, I decided to go ahead an
include the c front end bits.

Is this patch OK for gomp-4_0-branch? Julian is working on working on a
more complete implementation of the runtime. The runtime stub that I
included is only temporary.

Cesar
Cesar Philippidis
2014-10-04 22:32:46 UTC
Permalink
Post by Cesar Philippidis
Post by Ilmir Usmanov
Hi Cesar!
Thank you for the patch!
Post by Cesar Philippidis
This patch adds support for the async clause in the wait directive in
fortran. It should be pretty straight forward. The fortran FE already
supports the wait directive, but the async clause was introduced to the
wait directive in OpenACC 2.0 and that was missing in gomp-4_0-branch.
Yes, I've mostly focused on spec. ver. 1.0.
Post by Cesar Philippidis
Is this OK for gomp-4_0-branch?
http://www.pgroup.com/lit/presentations/cea-3.pdf (See slide 1-35)
!$acc wait(1) async(2)
However, your patch doesn't support this. Also, don't forget to check
whether a queue waits itself (for example, wait(1) async(1)).
In addition, it breaks current support of the directive (for example,
wait(1)).
Sorry for the delay. I encountered some problems with the runtime in our
internal branch, and that slowed things down a bit.
Anyway, you are correct, I broke the optional argument to wait in the
previous patch. This new patch addresses that and it also make the wait
construct conform with OpenACC 2.0. Specifically,
!$acc wait (1, 2) async (3)
should behave as ex[ected.
If you look at gfc_trans_oacc_wait_directive, you'll note that a call to
GOACC_wait is emitted for the wait directive. Since I had to add a
runtime library stub for that builtin function, I decided to go ahead an
include the c front end bits.
Is this patch OK for gomp-4_0-branch? Julian is working on working on a
more complete implementation of the runtime. The runtime stub that I
included is only temporary.
I noticed that I forgot to include the changes to gimplify.c in that
patch. This new patch includes those changes.

Cesar
Ilmir Usmanov
2014-10-06 10:56:44 UTC
Permalink
Hi Cesar!

Thank you for the update!
Post by Cesar Philippidis
Post by Cesar Philippidis
Post by Ilmir Usmanov
Hi Cesar!
Thank you for the patch!
Post by Cesar Philippidis
This patch adds support for the async clause in the wait directive in
fortran. It should be pretty straight forward. The fortran FE already
supports the wait directive, but the async clause was introduced to the
wait directive in OpenACC 2.0 and that was missing in gomp-4_0-branch.
Sorry for the delay. I encountered some problems with the runtime in our
internal branch, and that slowed things down a bit.
Anyway, you are correct, I broke the optional argument to wait in the
previous patch. This new patch addresses that and it also make the wait
construct conform with OpenACC 2.0. Specifically,
!$acc wait (1, 2) async (3)
should behave as ex[ected.
If you look at gfc_trans_oacc_wait_directive, you'll note that a call to
GOACC_wait is emitted for the wait directive. Since I had to add a
runtime library stub for that builtin function, I decided to go ahead an
include the c front end bits.
Is this patch OK for gomp-4_0-branch? Julian is working on working on a
more complete implementation of the runtime. The runtime stub that I
included is only temporary.
I noticed that I forgot to include the changes to gimplify.c in that
patch. This new patch includes those changes.
Cesar
As usual, I'll mostly focus on fortran part, since I don't know CFE and
ME well enough.

Nevertheless, is there a reason to differ C from Fortran in behavior of
matching int-expr-list? I mean, in C you support only integer literals
as parameter of wait, but in Fortran you also cover parameters.

Anyway, Fortran part.
Post by Cesar Philippidis
gfc_match_oacc_wait (void)
+ if (!gfc_resolve_expr (el->expr)
+ || el->expr->ts.type != BT_INTEGER || el->expr->rank != 0
+ || el->expr->expr_type != EXPR_CONSTANT)
+ {
+ gfc_error ("WAIT clause at %L requires a scalar INTEGER
expression",
+ &el->expr->where);
As you probably know, in Fortran one can define a function after whole
program.
So, since you are resolving wait-list during match, you don't cover this
case. But async clause works fine.
By the way, the same difference between wait and async presents in CFE.

Otherwise, Fortran part looks good for me.
--
Ilmir.
Cesar Philippidis
2014-10-07 02:35:53 UTC
Permalink
Post by Ilmir Usmanov
As usual, I'll mostly focus on fortran part, since I don't know CFE and
ME well enough.
Nevertheless, is there a reason to differ C from Fortran in behavior of
matching int-expr-list? I mean, in C you support only integer literals
as parameter of wait, but in Fortran you also cover parameters.
Either Thomas or Jim Norris worked on the CFE. I just included in this
patch to make gomp-4_0-branch more in sync with our internal branch.

There are a couple of other places, like the parameter for
vector_length, where C only supports integer literals. I don't know what
the plan is for those.
Post by Ilmir Usmanov
Anyway, Fortran part.
Post by Cesar Philippidis
gfc_match_oacc_wait (void)
+ if (!gfc_resolve_expr (el->expr)
+ || el->expr->ts.type != BT_INTEGER || el->expr->rank != 0
+ || el->expr->expr_type != EXPR_CONSTANT)
+ {
+ gfc_error ("WAIT clause at %L requires a scalar INTEGER
expression",
+ &el->expr->where);
As you probably know, in Fortran one can define a function after whole
program.
So, since you are resolving wait-list during match, you don't cover this
case. But async clause works fine.
I moved that check back into resolve_omp_clauses. So it functions now.
Post by Ilmir Usmanov
By the way, the same difference between wait and async presents in CFE.
Otherwise, Fortran part looks good for me.
Thomas, any thoughts on the CFE?

Thanks,
Cesar

Loading...