On 9/3/26 09:02, Tobias Burnus wrote:
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 82f0a65bd50..92d82f2f66c 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -5238,42 +5238,47 @@ Enable debugging output. The variable should be set to
@code{0}
If enabled, some debugging output is printed during execution.
This is currently not specified in more detail, and subject to change.
@end table
@node GOMP_RUNTIME_USM
@section @env{GOMP_RUNTIME_USM} -- Control runtime Unified Shared Memory
application
@cindex Environment Variable
@table @asis
@item @emph{Description}:
-Control the behavior of devices which can access host moemory, specifically
+Control the behavior of devices which can access host memory, specifically
whether data mapping copies data or uses self-mapping, such that the device
directly accesses the corresponding host memory. Setting the environment
variable to @code{DISABLED} does not make use of Unified Shared Memory by
default. Setting it to @code{AUTO} conditionally enables Unified Shared
-Memory on specific integrated GPUs (APUs, in the verbiage of AMD). In most
+Memory (USM) on specific integrated GPUs (APUs, in the verbiage of AMD). In
most
workloads on these types of GPUs, self-mapping is expected to reduce runtime
overhead. Lastly, setting it to @code{ENABLED} unconditionally attempts
to make use of Unified Shared Memory if the device claims to support it. Of
additional note, specifying the @code{unified_shared_memory} or
@code{self_maps} clauses with the @code{requires} directive causes that
behavior to take precedence over the behavior set by this environment
variable. For caveats around Unified Shared Memory, please consult
the relevant sections in @ref{Offload-Target Specifics}.
The changes to this paragraph are fine.
-When Unified Shared Memory is enabled, whether by a @code{requires} directive
-or by this environment variable being set to @code{AUTO} or @code{ENABLED},
-global static variables that appear in a @code{declare target} directive are
-not updated between device and host. That is, data copying under this model
-for global static variables is ignored.
+When unified-shared memory is enabled by this environment variable, the
+following is currently @emph{unsupported} for only global static variables
+that are specified in an @code{enter} clause on a @code{declare target}
+directive: specifying those variables in a @code{map} clause with @code{always}
+modifier on a @code{target} or @code{target data} directive. However, both
+@code{map} clauses without @code{always} modifier and using the
+@code{target update}, @code{target enter data}, or @code{target exit data}
+directives is fully supported. When the unsupported case is
+encountered, the program aborts with an error message.
+@c FIXME: This is tracked in PR libgomp/127186
We call it "Unified Shared Memory" in the previous paragraph, why switch
to "unified-shared memory" here?
I seriously cannot parse the rest of the paragraph at all, except for
the last sentence. :-( Among other points of confusion, the previous
paragraph says that you can enable USM in the code as well as by the
environment variable; do the limitations here apply *only* to the
environment variable use, or to the USM support in libgomp generally?
I wonder if you can rephrase this just to say that "It is currently
unsupported to ...." and get rid of the contorted wording about "the
following", as well as the long list of "both things" that *are*
supported (I think it's usually implicit that the feature is fully
implemented unless we say otherwise).
-Sandra
