mbox series

[0/3] openmp: Add support for iterators in OpenMP mapping clauses (C/C++)

Message ID ce9d902e-522f-46b7-b91b-13c7e43cf081@baylibre.com
Headers show
Series openmp: Add support for iterators in OpenMP mapping clauses (C/C++) | expand

Message

Kwok Cheung Yeung May 24, 2024, 7:57 p.m. UTC 
This series of patches adds support for OpenMP iterators in the 'map' 
clause of the 'target' construct (and it's derivatives such as 'target 
enter data'), and the 'to' and 'from' constructs of the 'target update' 
construct, currently for C and C++ only.

The approach in this patch differs from Tobias' WFC patch 
(https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586237.html) in 
that it does not rely on generating a callback function - instead, 
during Gimplification it generates loop(s) to evaluate every iteration 
of the iterator expression, and the results (i.e. addresses, as the 
expression should be an lvalue) are placed into a new array. This array 
is then used as the 'hostaddrs' entry for that particular map. Libgomp 
detects this (the corresponding size entry is set to SIZE_MAX, which 
shouldn't normally occur) and inserts the contents of the array into the 
map information before continuing on as normal.

Caveats:

- In section 2.21.7.1 of the OpenMP 5.1 standard, it states that 'If an 
expression that is used to form a list item in a map clause contains an 
iterator identifier, the list item instances that would result from 
different values of the iterator must not have the same containing array 
and must not have base pointers that share original storage' - this is 
currently not enforced (it would prohibit something like map 
(iterator(i=0:10), to: x[i]) while x is an int[]). As the expression in 
the iterator is more-or-less unbound, it would be very difficult to 
determine this at compile time. At runtime in libgomp, I suppose we 
could check every iterator-derived mapping to ensure that they all 
access unique entries in mem_map?

- The clause finishing currently generates spurious firstprivate maps - 
the patch currently just ignores them when in iterator clauses, but is 
there a better way of doing this?

- Clause reordering does not work too well with iterators. I believe the 
current approach to reordering on trunk is a bit buggy in the first 
place, so I just added enough to get the clauses through the pass 
without ICEing.

The GCC gomp tests and all the libgomp tests have been run without 
regressions on an x86-64 host with NVPTX offloading. Testing on AMD GCN 
to follow.

Kwok