[og12] '{c-c++-common,gfortran.dg}/gomp/uses_allocators-*' -> 'libgomp.{c-c++-common,fortran}/uses_allocators-*' (was: [PATCH, OpenMP] Implement uses_allocators clause for target regions)
Hi!
On 2022-05-06T21:20:48+0800, Chung-Lin Tang wrote:
> [...]
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/uses_allocators-1.c
> +#include
Etc.
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/uses_allocators-1.f90
> + use omp_lib
Etc.
Pushed to devel/omp/gcc-12 branch
commit 6e0ba07ff1859bc822c7220bfff18e7e9a147206
"'{c-c++-common,gfortran.dg}/gomp/uses_allocators-*' ->
'libgomp.{c-c++-common,fortran}/uses_allocators-*'",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From 6e0ba07ff1859bc822c7220bfff18e7e9a147206 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Mon, 30 Jan 2023 17:55:13 +0100
Subject: [PATCH] '{c-c++-common,gfortran.dg}/gomp/uses_allocators-*' ->
'libgomp.{c-c++-common,fortran}/uses_allocators-*'
Otherwise, for build-tree testing:
[...]/gcc/testsuite/c-c++-common/gomp/uses_allocators-1.c:4:10: fatal error: omp.h: No such file or directory
[...]/gcc/testsuite/c-c++-common/gomp/uses_allocators-2.c:3:10: fatal error: omp.h: No such file or directory
[...]/gcc/testsuite/c-c++-common/gomp/uses_allocators-3.c:4:10: fatal error: omp.h: No such file or directory
[...]/gcc/testsuite/gfortran.dg/gomp/uses_allocators-1.f90:5:7: Fatal Error: Cannot open module file 'omp_lib.mod' for reading at (1): No such file or directory
[...]/gcc/testsuite/gfortran.dg/gomp/uses_allocators-2.f90:4:7: Fatal Error: Cannot open module file 'omp_lib.mod' for reading at (1): No such file or directory
[...]/gcc/testsuite/gfortran.dg/gomp/uses_allocators-3.f90:4:7: Fatal Error: Cannot open module file 'omp_lib.mod' for reading at (1): No such file or directory
..., and thus corresponding FAILs, UNRESOLVEDs.
Fix-up for og12 commit dbc770c4351c8824e8083f8aff6117a6b4ba3c0d
"openmp: Implement uses_allocators clause".
gcc/testsuite/
* c-c++-common/gomp/uses_allocators-1.c: Cut.
* c-c++-common/gomp/uses_allocators-2.c: Likewise.
* c-c++-common/gomp/uses_allocators-3.c: Likewise.
* gfortran.dg/gomp/uses_allocators-1.f90: Likewise.
* gfortran.dg/gomp/uses_allocators-2.f90: Likewise.
* gfortran.dg/gomp/uses_allocators-3.f90: Likewise.
libgomp/
* testsuite/libgomp.c++/c++.exp (check_effective_target_c)
(check_effective_target_c++): New.
* testsuite/libgomp.c/c.exp (check_effective_target_c)
(check_effective_target_c++): Likewise.
* testsuite/libgomp.c-c++-common/uses_allocators-1.c: Paste.
* testsuite/libgomp.c-c++-common/uses_allocators-2.c: Likewise.
* testsuite/libgomp.c-c++-common/uses_allocators-3.c: Likewise.
* testsuite/libgomp.fortran/uses_allocators-1.f90: Likewise.
* testsuite/libgomp.fortran/uses_allocators-2.f90: Likewise.
* testsuite/libgomp.fortran/uses_allocators-3.f90: Likewise.
---
gcc/testsuite/ChangeLog.omp | 7 +++
libgomp/ChangeLog.omp | 11 +++
libgomp/testsuite/libgomp.c++/c++.exp | 7 +++
.../libgomp.c-c++-common}/uses_allocators-1.c | 0
.../libgomp.c-c++-common}/uses_allocators-2.c | 0
.../libgomp.c-c++-common}/uses_allocators-3.c | 0
libgomp/testsuite/libgomp.c/c.exp | 7 +++
.../testsuite/libgomp.fortran}/uses_allocators-1.f90 | 0
.../testsuite/libgomp.fortran}/uses_allocators-2.f90 | 0
.../testsuite/libgomp.fortran}/uses_allocators-3.f90 | 0
10 files changed, 32 insertions(+)
rename {gcc/testsuite/c-c++-common/gomp => libgomp/testsuite/libgomp.c-c++-common}/uses_allocators-1.c (100%)
rename {gcc/testsuite/c-c++-common/gomp => libgomp/testsuite/libgomp.c-c++-common}/uses_allocators-2.c (100%)
rename {gcc/testsuite/c-c++-common/gomp => libgomp/testsuite/libgomp.c-c++-common}/uses_allocators-3.c (100%)
rename {gcc/testsuite/gfortran.dg/gomp => libgomp/testsuite/libgomp.fortran}/uses_allocators-1.f90 (100%)
rename {gcc/testsuite/gfortran.dg/gomp => libgomp/testsuite/libgomp.fortran}/uses_allocators-2.f90 (100%)
rename {gcc/testsuite/gfortran.dg/gomp => libgomp/testsuite/libgomp.fortran}/uses_allocators-3.f90 (100%)
diff --git a/gcc/testsuite/ChangeLog.omp b/gcc/testsuite/ChangeLog.omp
index 9f9d5a10ac3..936e7af0945 100644
--- a/gcc/testsuite/ChangeLog.omp
+++ b/gcc/testsuite/ChangeLog.omp
@@ -1,5 +1,12 @@
2023-02-09 Thomas Schwinge
+ * c-c++-common/gomp/uses_allocators-1.c: Cut.
+ * c-c++-common/gomp/uses_allocators-2.c: Likewise.
+ * c-c++-common/gomp/uses_allocators-3.c: Likewise.
+ * gfortran.dg/gomp/uses_allocators-1.f90: Likewise.
+ * gfortran.dg/gomp/uses_allocators-2.f90: Likewise.
+ * gfortran.dg/gomp/uses_allocators-3.f90: Likewise.
+
* c-c++-common/gomp/alloc-pinned-1.c: Cut.
* gfortran.dg/gomp/allocate-4.f90: Fix 'omp_allocator_handle_kind'
diff --git a/libgomp/ChangeLog.omp
Re: [PATCH, OpenMP] Implement uses_allocators clause for target regions
Hi Chung-Lin,
thanks for the patch – and some comments from my side.
On 06.05.22 15:20, Chung-Lin Tang wrote:
For user defined allocator handles, this allows target regions to assign
memory space and traits to allocators, and automatically calls
omp_init/destroy_allocator() in the beginning/end of the target region.
Can please also handle the new clause in Fortran's dump-parse-tree.cc?
I did see some split handling in C, but not in Fortran; do you also need
to up update gfc_split_omp_clauses in Fortran's trans-openmp.cc?
Actually, glancing at the testcases, no combined construct (like
"omp target parallel") is used, I think that would be useful because of ↑.
+/* OpenMP 5.2:
+ uses_allocators ( allocator-list )
That's not completely true: uses_allocators is OpenMP 5.1.
However, 5.1 only supports (for non-predefined allocators):
uses_allocators( allocator(traits) )
while OpenMP 5.2 added modifiers:
uses_allocatrors( traits(...), memspace(...) : allocator )
and deprecated the 5.1 'allocator(traits)'. (Scheduled for removal in OMP 6.0)
The advantage of 5.2 syntax is that a memory space can be defined.
BTW: This makes uses_allocators the first OpenMP 5.2 feature which
will make it into GCC :-)
gcc/fortran/openmp.cc:
+ if (gfc_get_symbol ("omp_allocator_handle_kind", NULL, )
+ || !sym->value
+ || sym->value->expr_type != EXPR_CONSTANT
+ || sym->value->ts.type != BT_INTEGER)
+{
+ gfc_error ("OpenMP % constant not found by "
+ "% clause at %C");
+ goto error;
+}
+ allocator_handle_kind = sym;
I think you rather want to use
gfc_find_symbol ("omp_...", NULL, true, )
|| sym == NULL
where true is for parent_flag to search also the parent namespace.
(The function returns 1 if the symbol is ambiguous, 0 otherwise -
including 0 + sym == NULL when the symbol could not be found.)
|| sym->attr.flavor != FL_PARAMETER
|| sym->ts.type != BT_INTEGER
|| sym->attr.dimension
Looks cleaner than to access sym->value. The attr.dimension is just
to makes sure the user did not smuggle an array into this.
(Invalid as omp_... is a reserved namespace but users will still do
this and some are good in finding ICE as hobby.)
* * *
However, I fear that will fail for the following two examples (both untested):
use omp_lib, my_kind = omp_allocator_handle_kind
integer(my_kind) :: my_allocator
as this gives 'my_kind' in the symtree->name (while symtree->n.sym->name is
"omp_...").
Hence, by searching the symtree for 'omp_...' the symbol will not be found.
It will likely also fail for the following more realistic example:
module m
use omp_lib
implicit none
private
integer(omp_allocator_handle_kind), public :: my_allocator
type(omp_alloctrait), public, parameter :: my_traits(*) = [...]
end module
subroutine foo
use m
use omp_lib, only: omp_alloctrait
implicit none
! currently, same scope is required - makes sense for C and 'const' but
! not for Fortran's parameters; restriction might be lifted/clarified in
! next OpenMP version:
type(omp_alloctrait), parameter :: traits_array(*) = my_traits
integer :: A(200)
A = 0
!$omp target uses_allocators(my_allocator(traits_array)
allocate(my_allocator:A) firstprivate(A)
...
!$omp end target
end
In this case, omp_allocator_handle_kind is not in the namespace of 'foo'
but the code should be still valid. Thus, an alternative would be to hard-code
the value - as done for the depobj. As we have:
integer, parameter :: omp_allocator_handle_kind = c_intptr_t
integer, parameter :: omp_memspace_handle_kind = c_intptr_t
that would be
sym->ts.type == BT_CHARACTER
sym->ts.kind == gfc_index_integer_kind
for the allocator variable and the the memspace kind.
However, I grant that either example is not very typical. The second one is more
natural – such a code will very likely be written in the real world. But not
with uses_allocators but rather with "!$omp requires dynamic_allocators" and
omp_init_allocator().
Thoughts?
* * *
gcc/fortran/openmp.cc
+ if (++i > 2)
+ {
+ gfc_error ("Only two modifiers are allowed on % "
+ "clause at %C");
+ goto error;
+ }
+
Is this really needed? There is a check for multiple traits and multiple
memspace
Thus, 'trait(),memspace(),trait()' is already handled and
'trait(),something' give a break and will lead to an error as in that case
a ':' and not ',something' is expected.
+ if (gfc_match_char ('(') == MATCH_YES)
+ {
+ if (memspace_seen || traits_seen)
+ {
+ gfc_error ("Modifiers cannot be used with legacy "
+ "array syntax at %C");
I wouldn't uses the term 'array synax' to denote
uses_allocators(allocator (alloc_array) )
How about:
error: "Using both modifiers and allocator variable with traits argument"
(And I think 'deprecated' is better than 'legacy', if we really want to use it.)
+ if (traits_sym->ts.type !=
[PATCH, OpenMP] Implement uses_allocators clause for target regions
Hi Jakub, this patch implements the uses_allocators clause for OpenMP target regions. For user defined allocator handles, this allows target regions to assign memory space and traits to allocators, and automatically calls omp_init/destroy_allocator() in the beginning/end of the target region. For pre-defined allocators (i.e. omp_..._mem_alloc names), this is a no-op, such clauses are not created. Asides from the front-end portions, the target region transforms are done in gimplify_omp_workshare. This patch also includes added changes to enforce the "allocate allocator must be also in a uses_allocator clause", as to mentioned in[1]. This is done during gimplify_scan_omp_clauses. [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594039.html Tested on mainline, please see if this is okay. Thanks, Chung-Lin 2022-05-06 Chung-Lin Tang gcc/c-family/ChangeLog: * c-omp.cc (c_omp_split_clauses): Add OMP_CLAUSE_USES_ALLOCATORS case. * c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_USES_ALLOCATORS. gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_clause_name): Add case for uses_allocators clause. (c_parser_omp_clause_uses_allocators): New function. (c_parser_omp_all_clauses): Add PRAGMA_OMP_CLAUSE_USES_ALLOCATORS case. (OMP_TARGET_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_USES_ALLOCATORS to mask. * c-typeck.cc (c_finish_omp_clauses): Add case handling for OMP_CLAUSE_USES_ALLOCATORS. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_clause_name): Add case for uses_allocators clause. (cp_parser_omp_clause_uses_allocators): New function. (cp_parser_omp_all_clauses): Add PRAGMA_OMP_CLAUSE_USES_ALLOCATORS case. (OMP_TARGET_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_USES_ALLOCATORS to mask. * semantics.cc (finish_omp_clauses): Add case handling for OMP_CLAUSE_USES_ALLOCATORS. fortran/ChangeLog: * gfortran.h (struct gfc_omp_namelist): Add memspace_sym, traits_sym fields. (OMP_LIST_USES_ALLOCATORS): New list enum. * openmp.cc (enum omp_mask2): Add OMP_CLAUSE_USES_ALLOCATORS. (gfc_match_omp_clause_uses_allocators): New function. (gfc_match_omp_clauses): Add case to handle OMP_CLAUSE_USES_ALLOCATORS. (OMP_TARGET_CLAUSES): Add OMP_CLAUSE_USES_ALLOCATORS. (resolve_omp_clauses): Add "USES_ALLOCATORS" to clause_names[]. * trans-array.cc (gfc_conv_array_initializer): Adjust array index to always be a created tree expression instead of NULL_TREE when zero. * trans-openmp.cc (gfc_trans_omp_clauses): For ALLOCATE clause, handle using gfc_trans_omp_variable for EXPR_VARIABLE exprs. Add handling of OMP_LIST_USES_ALLOCATORS case. * types.def (BT_FN_VOID_PTRMODE): Define. (BT_FN_PTRMODE_PTRMODE_INT_PTR): Define. gcc/ChangeLog: * builtin-types.def (BT_FN_VOID_PTRMODE): Define. (BT_FN_PTRMODE_PTRMODE_INT_PTR): Define. * omp-builtins.def (BUILT_IN_OMP_INIT_ALLOCATOR): Define. (BUILT_IN_OMP_DESTROY_ALLOCATOR): Define. * tree-core.h (enum omp_clause_code): Add OMP_CLAUSE_USES_ALLOCATORS. * tree-pretty-print.cc (dump_omp_clause): Handle OMP_CLAUSE_USES_ALLOCATORS. * tree.h (OMP_CLAUSE_USES_ALLOCATORS_ALLOCATOR): New macro. (OMP_CLAUSE_USES_ALLOCATORS_MEMSPACE): New macro. (OMP_CLAUSE_USES_ALLOCATORS_TRAITS): New macro. * tree.cc (omp_clause_num_ops): Add OMP_CLAUSE_USES_ALLOCATORS. (omp_clause_code_name): Add "uses_allocators". * gimplify.cc (gimplify_scan_omp_clauses): Add checking of OpenMP target region allocate clauses, to require a uses_allocators clause to exist for allocators. (gimplify_omp_workshare): Add handling of OMP_CLAUSE_USES_ALLOCATORS for OpenMP target regions; create calls of omp_init/destroy_allocator around target region body. gcc/testsuite/ChangeLog: * c-c++-common/gomp/uses_allocators-1.c: New test. * c-c++-common/gomp/uses_allocators-2.c: New test. * gfortran.dg/gomp/uses_allocators-1.f90: New test. * gfortran.dg/gomp/uses_allocators-2.f90: New test. * gfortran.dg/gomp/uses_allocators-3.f90: New test. diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def index 3a7cecdf087..be3e6ff697e 100644 --- a/gcc/builtin-types.def +++ b/gcc/builtin-types.def @@ -283,6 +283,7 @@ DEF_FUNCTION_TYPE_1 (BT_FN_DFLOAT32_DFLOAT32, BT_DFLOAT32, BT_DFLOAT32) DEF_FUNCTION_TYPE_1 (BT_FN_DFLOAT64_DFLOAT64, BT_DFLOAT64, BT_DFLOAT64) DEF_FUNCTION_TYPE_1 (BT_FN_DFLOAT128_DFLOAT128, BT_DFLOAT128, BT_DFLOAT128) DEF_FUNCTION_TYPE_1 (BT_FN_VOID_VPTR, BT_VOID, BT_VOLATILE_PTR) +DEF_FUNCTION_TYPE_1 (BT_FN_VOID_PTRMODE, BT_VOID, BT_PTRMODE) DEF_FUNCTION_TYPE_1 (BT_FN_VOID_PTRPTR, BT_VOID, BT_PTR_PTR) DEF_FUNCTION_TYPE_1 (BT_FN_VOID_CONST_PTR, BT_VOID, BT_CONST_PTR) DEF_FUNCTION_TYPE_1 (BT_FN_UINT_UINT,
