-fopenmp-ompt(-details): Now with a patch - based on my original
proposal but I reworded it quite a bit.
Comments or remarks?
* * *
Thomas Schwinge wrote:
For some OpenMP constructs
Maybe 'certain' instead of 'some'?
I am not sure what's better both have connotations that I don't like. In
any case, the wording afterward should make clear what happens.
I have kept 'some'.
I like in the current text that we say "calls [into libgomp]", which
intends to help the user understand what kind of calls these are?
Or, even better, as you have it below: "calls into the OpenMP runtime",
to avoid implementor-speak?
Done so when rewording.
region instead of only on region entry. This improves the OMPT
tracing
Is "OMPT tracing" the correct term to use?
I hope the current wording is better. OpenMP distinguishes between
events and callbacks (which can also only be invoked if registered by a
tool). It also talks about "OMPT defines mechanisms to … notification
about events, to trace activity".
I hope the new wording is both clear and (mostly) correct in terms of
spec wording.
at expense of additional calls. In particular, the
additional calls will be added for static worksharing loops,
static worksharing @code{dispatch}
Shoud this probably be 'distribute' instead of 'dispatch'?
Yes - the callback is 'dispatch' and the event occurs for 'distribute'.
When writing email review comments, I am more lazy then writing actual
patches (cf. also previous email); I hope the real patch is fine in this
regard.
Add additional calls into the OpenMP runtime that might affect
the performance
Maybe "might negatively affect performance"?
The current wording is:
"Add additional calls …, which might have a measurable effect on the
performance."
I think rewording it to include negative makes it more clumsy – and
anyone who thinks that additional calls make it faster should think
again, esp. as the flag is not enabled by default …
but further improves OMPT tracing. In particular,
dispatch callbacks
Should 'dispatch' get some mark-up here? Or, prefix with "OMPT"?
@code{} makes sense, but clustering the wording with OMPT does not
really improve the readabilty (IMHO).
Tobias
OpenMP: docs - improve -fopenmp-openmp(-detailed) description + update impl. status
invoke.texi: Improve the wording for -fopenmp-openmp(-detailed) that was
added in r17-2288-gab0dd7d5e16fcd.
libgomp.texi: Mark OpenMP 5.1's 'device_type(...)' for variables on
'declare target' as partially implemented as parsing support was added for
C/C++ in r10-2342-g77eb117f588686 and for Fortran in r11-2858-gd58e7173ef964d.
(device_type: It actually seems to work fine, even though there is almost no
code to handle 'host' differently; still host/nohost handling should be
improved for vars and funcs; hence, marked as only partial not fully
wrotesupported.)
gcc/ChangeLog:
* doc/invoke.texi (-fopenmp-openmp, -fopenmp-openmp-detailed): Improve
wording.
libgomp/ChangeLog:
* libgomp.texi (OpenMP 5.1 Impl Status): Mark device_type on vars
in declare target as 'P'.
gcc/doc/invoke.texi | 21 ++++++++++++++-------
libgomp/libgomp.texi | 3 ++-
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2e5c9d6788e..bae4fcd47e8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5623,18 +5623,25 @@ to the current task region, independent of the specified @code{bind} clause.
@opindex fno-openmp-ompt
@cindex OpenMP OMPT
@item -fopenmp-ompt
-Emit additional calls into libgomp, enabling OMPT callbacks around some OpenMP
-worksharing constructs (namely statically scheduled @code{for} and
-@code{distribute}, @code{single}, @code{masked} and @code{master}), so that an
-OMPT tool can observe their start and end. Requires @option{-fopenmp}.
+For some OpenMP constructs, generate calls into the OpenMP runtime before and
+after the region instead of only on region entry. For those constructs, the
+additional calls are only needed to provide better tracing results in tools
+using the OMPT interface and have a small overhead. The extra calls are
+generated for the @code{single}, @code{masked}, and @code{master} constructs
+and with static scheduling for the @code{distribute} and worksharing loops
+constructs. Requires @option{-fopenmp}.
@opindex fopenmp-ompt-detailed
@opindex fno-openmp-ompt-detailed
@cindex OpenMP OMPT
@item -fopenmp-ompt-detailed
-Like @option{-fopenmp-ompt}, and additionally emit calls into libgomp, enabling
-OMPT dispatch callbacks that get called at the beginning of each workshare chunk
-for statically scheduled @code{for} and @code{distribute}. Requires
+Add additional calls into the OpenMP runtime for more detailed tracing via OMPT,
+which might have a measurable effect on the performance. The option enables
+additional constructs to issue events for the @code{dispatch} callback, which
+is invoked when begining to execute a section or a collapsed iteration in a
+@code{taskloop} or worksharing construct. With that option, also the
+@code{distribute} and worksharing loop constructs with static scheduling can
+dispatch the callback. Implies @option{-fopenmp-ompt} and requires
@option{-fopenmp}.
@opindex fopenmp-target-simd-clone
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 687ae1a7cbc..e1b8cc0b90f 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -363,7 +363,8 @@ to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab
@code{IMPORT}, and @code{IMPLICIT} as invalid @tab N @tab
@item Optional comma between directive and clause in the @code{#pragma} form @tab Y @tab
@item @code{indirect} clause in @code{declare target} @tab Y @tab
-@item @code{device_type(nohost)}/@code{device_type(host)} for variables @tab N @tab
+@item @code{device_type(nohost)}/@code{device_type(host)} for variables @tab P @tab
+ Initial support
@item @code{present} modifier to the @code{map}, @code{to} and @code{from}
clauses @tab Y @tab
@item Changed interaction between @code{declare target} and OpenMP context
