[wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update

Update the OpenMP status for features that were added in the last months.

Comments/suggestions? Okay to commit?

Tobias
-----------------
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

On Fri, Sep 02, 2022 at 09:37:57AM +0200, Tobias Burnus wrote:
> Update the OpenMP status for features that were added in the last months.
> 
> Comments/suggestions? Okay to commit?
> 
> Tobias
> -----------------
> 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

> gcc-13/changes.html + projects/gomp/: OpenMP update
> 
> * htdocs/gcc-13/changes.html: Update OpenMP entry; fix html syntax.
> * htdocs/projects/gomp/index.html: Update OpenMP 5.x implementation status;
>   add missing item from libgomp.texi + flip two items to have same order as
>   the .texi.
> 
>  htdocs/gcc-13/changes.html      | 42 ++++++++++++++++++++++++++++++++---------
>  htdocs/projects/gomp/index.html | 40 +++++++++++++++++++++++++++++----------
>  2 files changed, 63 insertions(+), 19 deletions(-)

I think some of the </li> or <tr> issues have been fixed in the mean time,
so it might not apply cleanly.
LGTM, whether you want to update it further for doacross/omp_cur_iteration
now or whether we do it incrementally up to you.

	Jakub

Hi Tobias,

On Fri, 2 Sep 2022, Tobias Burnus wrote:
> Update the OpenMP status for features that were added in the last months.

I made a couple of incremental edits. See below for what I just pushed
(and please speak up if you see any issues).

Gerald


commit 2f870cba5aaaa8c81449beb618a9030824360a25
Author: Gerald Pfeifer <gerald@pfeifer.com>
Date:   Sat Jan 14 22:44:49 2023 +0100

    gcc-13: Various editorial changes around OMP entries

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 96d47903..08e36fb3 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -54,10 +54,10 @@ a work-in-progress.</p>
   <ul>
     <li>
       Reverse offload is now supported and the all clauses to the
-      <code>requires</code> directive are now accepted; however, the
+      <code>requires</code> directive are now accepted. However, the
       <code>requires_offload</code>, <code>unified_address</code>
-      and <code>unified_shared_memory</code> clauses cause that the
-      only available device is the initial device (the host). Fortran now
+      and <code>unified_shared_memory</code> clauses imply the initial
+      device (= the host) as the only available device. Fortran now
       supports non-rectangular loop nests, which were added for C/C++ in GCC 11.
     </li>
     <li>
@@ -72,27 +72,27 @@ a work-in-progress.</p>
       syntax in C/C++ and device-specific ICV settings with environment variables
       are now supported.</li>
     <li>
-      Initial support for OpenMP 5.2 features have been added: Support for
+      Initial support for OpenMP 5.2 features has been added:
       <code>firstprivate</code> and <code>allocate</code> clauses on the
-      <code>scope</code> construct and the OpenMP 5.2 syntax of the
-      <code>linear</code> clause; the new enum/constants
+      <code>scope</code> construct; the OpenMP 5.2 syntax of the
+      <code>linear</code> clause; new enum/constants
       <code>omp_initial_device</code> and <code>omp_invalid_device</code>; and
       optionally omitting the map-type in <code>target enter/exit data</code>.
       The <code>enter</code> clause (as alias for <code>to</code>) has been added
-      to the <code>declare target</code> directive. Also added has been the
+      to the <code>declare target</code> directive. Also added have been the
       <code>omp_in_explicit_task</code> routine and the <code>doacross</code>
       clause as alias for <code>depend</code> with
       <code>source</code>/<code>sink</code> modifier.
     </li>
     <li>
-      The <code>_ALL</code> suffix to the device-scope environment variables,
+      The <code>_ALL</code> suffix to the device-scope environment variables
       added in Technical Report (TR11) is already handled.
     </li>
     <li>
       For user defined allocators requesting high bandwidth or large capacity
       memspaces or interleaved partitioning, the <a
       href="http://memkind.github.io/memkind/">memkind</a> library is used,
-      if available at runtime.
+      if available at run time.
     </li>
   </ul>
   </li>

Hi Gerald,

On 14.01.23 22:47, Gerald Pfeifer wrote:

> I made a couple of incremental edits. See below for what I just pushed
> (and please speak up if you see any issues).
>
> commit 2f870cba5aaaa8c81449beb618a9030824360a25

...

> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> @@ -54,10 +54,10 @@ a work-in-progress.</p>

...

> +      <code>requires</code> directive are now accepted. However, the
>         <code>requires_offload</code>, <code>unified_address</code>
> -      and <code>unified_shared_memory</code> clauses cause that the
> -      only available device is the initial device (the host). Fortran now
> +      and <code>unified_shared_memory</code> clauses imply the initial
> +      device (= the host) as the only available device. Fortran now

I really stumble over the "as" – that sounds wrong and I fail to parse this part.
I think it should be "is".

On the technical side, in principle, available devices are the host (aka "initial device") –
and all installed** (nonhost) devices – in our case nvptx and (amd)gcn GPUs.

However, when using 'requires', all installed devices which do not fulfill
the requirement(s) are removed from the list of available devices. In case of
'dynamic_allocators', all devices support it, in case of 'reverse_offload' all installed
amdgcn devices are filtered out and, for unified-shared memory,* neither nvptx nor
amdgcn support it – and are removed from the list – such that at the end, only
the host remains. (Hence, device code ('target regions') will run on the host
→ host fallback.)

BTW: Before the release, further updates to changes.html are required. – For instance,
as alluded in the previous paragraph, 'reverse offload' is (now) supported for nvptx.
(But not yet with amdgcn.)

Tobias

(*) There is support for unified-shared memory for both nvptx and gcn,
but the existing patches either have to be reviewed or to be revised.

(**) I coined the term 'installed device'. OpenMP since TR11 contains some
definitions for 'available devices' – which consists of the union of supported
and accessible devices (possibly after sorting and further filtering). Namely:

accessible devices – The host device and all non-host devices accessible for execution.

supported devices – The host device and all non-host devices supported by the
implementation for execution of target code for which the device-related requirements
of the requires directive are fulfilled.

The available-devices-var is in turn by default "*" – where "* expands to all accessible
and supported devices". (The device list can be further filtered and sorted via
the environment variable OMP_AVAILABLE_DEVICES.)

-----------------
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

Hi Tobias,

On Mon, 16 Jan 2023, Tobias Burnus wrote:
>>         <code>requires_offload</code>, <code>unified_address</code>
>> -      and <code>unified_shared_memory</code> clauses cause that the
>> -      only available device is the initial device (the host). Fortran now
>> +      and <code>unified_shared_memory</code> clauses imply the initial
>> +      device (= the host) as the only available device. Fortran now
> I really stumble over the "as" – that sounds wrong and I fail to parse this
> part.
> I think it should be "is".

happy to make this change. Or do you have an idea to reframe the 
sentence (or paragraph) altogether?

(I'm not an expert in that area and so find your description quite
helpful. And based on that "as" -> "is" seems to be sufficient?)

What is your recommendation?

> BTW: Before the release, further updates to changes.html are required.

Keep them coming! :-)

Thanks,
Gerald

Hi Gerald,

On 16.01.23 23:16, Gerald Pfeifer wrote:
> On Mon, 16 Jan 2023, Tobias Burnus wrote:
>>>          <code>requires_offload</code>, <code>unified_address</code>
>>> -      and <code>unified_shared_memory</code> clauses cause that the
>>> -      only available device is the initial device (the host). Fortran now
>>> +      and <code>unified_shared_memory</code> clauses imply the initial
>>> +      device (= the host) as the only available device. Fortran now
>> I really stumble over the "as" – that sounds wrong and I fail to parse this
>> part. I think it should be "is".
> happy to make this change. Or do you have an idea to reframe the
> sentence (or paragraph) altogether?

Actually, I thinking about it again, the "imply" is also misleading – by
itself the restrictions do not imply that accelerators/GPUs are not
supported; that's only implied in GCC as the libgomp plugins for nvptx
and amdgcn don't handle it, yet.

How about the following? I put the other change into its own bullet
point to be less confusing, completely rewording the remaining item and
mention reverse offload support.

(Reverse offload is: While being in a target region ('omp target', i.e.
running code targeted for an offload device), it is possible to execute
a code on the host. — If there is no available non-host device, the
target region will run on the host (host fallback); in that case,
reverse offload is trivial (as host code calls host code).)

>> BTW: Before the release, further updates to changes.html are required.
> Keep them coming! :-)

Actually, I think only one change was missing (looking at
libgomp/libgomp.texi), unless some more pending patches are accepted. –
I have now included that change in the attached patch.

Tobias
-----------------
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

On Wed, Jan 18, 2023 at 01:39:43PM +0100, Tobias Burnus wrote:
> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> @@ -53,12 +53,19 @@ a work-in-progress.</p>
>    <li id="openmp"><a href="https://gcc.gnu.org/projects/gomp/">OpenMP</a>
>    <ul>
>      <li>
> -      Reverse offload is now supported and the all clauses to the
> -      <code>requires</code> directive are now accepted. However, the
> -      <code>requires_offload</code>, <code>unified_address</code>
> -      and <code>unified_shared_memory</code> clauses imply the initial
> -      device (= the host) as the only available device. Fortran now
> -      supports non-rectangular loop nests, which were added for C/C++ in GCC 11.
> +      Reverse offload is now supported with nvptx devices. Additionally, the
> +      <code>requires</code> handling has been improved and all clauses are
> +      now accepted. If a requirement cannot be fulfilled for an accessible
> +      device, this device is excluded from the list of available devices. This
> +      may imply that the only device left is the host (the initial device).
> +      In particular, <code>requires_offload</code> is currently unsupported on
> +      AMD GCN devices while <code>unified_address</code> and
> +      <code>unified_shared_memory</code> are unsupported by all non-host
> +      devices.

The above looks good to me.

> +    </li>
> +    <li>
> +      OpenMP 5.0: Fortran now supports non-rectangular loop nests, which were
> +      added for C/C++ in GCC 11.

But because of the sorry_at I'd say "supports some" instead of "supports".
And similarly in the libgomp texi as well as gomp/index.html clarify it is
full C/C++ support (I'll look at PR108435 soon) and say the Fortran support
is still partial.

> --- a/htdocs/projects/gomp/index.html
> +++ b/htdocs/projects/gomp/index.html
> @@ -547,9 +547,14 @@ than listed, depending on resolved corner cases and optimizations.</p>
>      <td></td>
>    </tr>
>    <tr>
> -    <td><code>align</code> clause/modifier in <code>allocate</code> directive/clause and <code>allocator</code> directive</td>
> +    <td><code>align</code> clause in <code>allocate</code> directive</td>
> +    <td class="unsupported">No</td>
> +    <td></td>
> +  </tr>
> +  <tr>
> +    <td><code>align</code> modifier in <code>allocate</code> clause</td>
>      <td class="supported"><a href="../../gcc-12/changes.html#languages">GCC&nbsp;12</a></td>
> -    <td>C/C++ on clause only</td>
> +    <td></td>
>    </tr>
>    <tr>
>      <td><code>thread_limit</code> clause to <code>target</code> construct</td>


	Jakub

On Wed, 18 Jan 2023, Tobias Burnus wrote:
> How about the following? I put the other change into its own bullet
> point to be less confusing, completely rewording the remaining item and
> mention reverse offload support.

Thank you, Tobias, for the explanation and the updated patch.

As Jakub said, this looks good to go (modulo his one note).


Just one question: Does "all clauses are now accepted" refer to 
 - all (as in 100% of possible clauses), or
 - <code>all</code> (as in a special kind of clause)? 

(Asking due to the wording in the original version of the patch which felt 
like the latter.)

Gerald

On 21.01.23 13:48, Gerald Pfeifer wrote:
> Just one question: Does "all clauses are now accepted" refer to
>   - all (as in 100% of possible clauses), or
>   - <code>all</code> (as in a special kind of clause)?

The former – besides the listed 'unified_shared_memory',
'unified_address' and 'reverse_offload' clauses, there are
'dynamic_allocators' and 'atomic_default_mem_order' which are handled in
the compiler front end (by being ignored (always fulfilled) and by used
its argument as default value, respectively).

Thanks for the review. (I will commit/update the patch later.)

Tobias

-----------------
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

Now committed with the suggestions taken into account.

That is: for non-rect loop-nest support, add 'some' / set back to
partial. I also changed the already-in-GCC-11 wording as it was a bit
unclear to which word/topic the "which" in the original patch referred
to - and the "some" made it even worse.

Tobias
-----------------
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

On Mon, 23 Jan 2023, Tobias Burnus wrote:
> Now committed with the suggestions taken into account.

Nice - this feels rather clear to me (as a non-expert) now. :-)

Thanks,
Gerald