This is the mail archive of the
mailing list for the GCC project.
[PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
- From: Ilmir Usmanov <i dot usmanov at samsung dot com>
- To: gcc-patches at gcc dot gnu dot org, Thomas Schwinge <thomas at codesourcery dot com>, jakub at redhat dot com
- Cc: Evgeny Gavrin <e dot gavrin at samsung dot com>, GarbuzovViacheslav <v dot garbuzov at samsung dot com>, Dmitri Botcharnikov <dmitry dot b at samsung dot com>
- Date: Thu, 23 Jan 2014 22:01:19 +0400
- Subject: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
- Authentication-results: sourceware.org; auth=none
Jakub, could you review these patches, if they are OK to gomp-4_0-branch?
Thomas, please, have a look whether this implementation applies current
OpenACC support style.
These patches port OpenACC 1.0 support in fortran front-end from
openacc-1_0-branch to gomp-4_0-branch. In addition, they extend
middle-end infrastructure with necessary GENERIC nodes.
Patches support almost all directives (except loop) and all clauses from
the specification ver. 1.0 (without subarrays).
In addition to OpenACC version 1.0, patches add functionality from
OpenACC 2.0: enter data and exit data directives.
Patches stub gimplification of OpenACC constructs and directives, except
OACC_PARALLEL node, to prevent crashes.
I didn't port loop directive, since in openacc-1_0-branch we consider it
as OpenACC construct, like kernels or parallel. Hence, OpenACC loop and
OpenMP for directives differ. It means there are no checks in C FE (in
openacc-1_0-branch) and the functionality will be modified, in both FEs
As far as loop directive doesn't exist in GENERIC, fortran FE doesn't
transform it from internal EXEC_OACC_LOOP statement. Consequenly, there
are no tests to check the directive.
Lately, I'm going to port loop directive, too.
Inspite of the fact that subarrays do exist in openacc-1_0-branch, they
don't present in patches. Currently, we are using our own GENERIC nodes
to represent subarrays. I'm going to replace them with existing
functionality, like ARRAY_RANGE_REF.
Full list of supported fuctionality is the following:
Name front-end GENERIC tests
parallel Y Y Y
kernels Y Y Y
data Y Y Y
host_data Y Y Y
loop Y N N
update Y Y Y
wait Y Y N
cache Y Y N
declare Y Y Y
kernels loop Y N N
parallel loop Y N N
enter data (2.0) Y Y Y
exit data (2.0) Y Y Y
Name front-end GENERIC tests
async Y Y Y
wait Y Y Y
num_gangs Y Y Y
num_workers Y Y Y
vector_length Y Y Y
if Y Y Y
reduction Y Y Y
copy Y Y Y
copyin Y Y Y
copyout Y Y Y
create Y Y Y
delete (2.0) Y Y Y
present Y Y Y
present_or_copy Y Y Y
present_or_copyin Y Y Y
present_or_copyout Y Y Y
present_or_create Y Y Y
deviceptr Y Y Y
private Y Y Y
firstprivate Y Y Y
default(none) (2.0) Y N Y
collapse Y Y N
gang Y Y N
worker Y Y N
vector Y Y N
seq Y Y N
auto (2.0) Y N N
tile Y N N
independent Y Y N
device_resident Y Y N
Successfully bootstraps on x86_64 with no regressions.
OK to commit?