public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic
@ 2023-09-25 18:24 Tobias Burnus
  2023-09-26  7:34 ` Richard Biener
  2023-09-26  7:54 ` Jakub Jelinek
  0 siblings, 2 replies; 5+ messages in thread
From: Tobias Burnus @ 2023-09-25 18:24 UTC (permalink / raw)
  To: gcc-patches, Jakub Jelinek

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

I stumbled over this during the ARM64 talk at the cauldron as they
consider using -fopenmp-simd by default.

→ https://gcc.gnu.org/wiki/cauldron2023 (I put my talk/BoF slides up;
others aren't, yet)

I did stumble over 'omp loop' with SIMD. It turns out that -fopenmp-simd
just turns 'loop' into 'simd', ignoring whatever value the user has
specified for the bind value.

Additionally, [[omp::decl(...)]] was missing.

Any comment to that patch before I commit it?

Tobias

PS: the [[omp::...]] needs a 'C++' → 'C/C++' change once omp:: support
with C23's attributes is in.
-----------------
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

[-- Attachment #2: omp-decl-doc.diff --]
[-- Type: text/x-patch, Size: 2277 bytes --]

invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic

gcc/ChangeLog:

	PR middle-end/111547
	* doc/invoke.texi (-fopenmp): Mention C++11 [[omp::decl(...)]] syntax.
	(-fopenmp-simd): Likewise. Clarify 'loop' directive semantic.

 gcc/doc/invoke.texi | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 146b40414b0..89c539f06c2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2766,8 +2766,9 @@ can be omitted, to use a target-specific default value.
 @cindex OpenMP parallel
 @item -fopenmp
 Enable handling of OpenMP directives @code{#pragma omp} in C/C++,
-@code{[[omp::directive(...)]]} and @code{[[omp::sequence(...)]]} in C++ and
-@code{!$omp} in Fortran.  When @option{-fopenmp} is specified, the
+@code{[[omp::directive(...)]]}, @code{[[omp::sequence(...)]]} and
+@code{[[omp::decl(...)]]} in C++ and @code{!$omp} in Fortran.
+When @option{-fopenmp} is specified, the
 compiler generates parallel code according to the OpenMP Application
 Program Interface v4.5 @w{@uref{https://www.openmp.org}}.  This option
 implies @option{-pthread}, and thus is only supported on targets that
@@ -2779,11 +2780,14 @@ have support for @option{-pthread}. @option{-fopenmp} implies
 @cindex SIMD
 @item -fopenmp-simd
 Enable handling of OpenMP's @code{simd}, @code{declare simd},
-@code{declare reduction}, @code{assume}, @code{ordered}, @code{scan},
-@code{loop} directives and combined or composite directives with
+@code{declare reduction}, @code{assume}, @code{ordered}, @code{scan}
+and @code{loop} directive, and of combined or composite directives with
 @code{simd} as constituent with @code{#pragma omp} in C/C++,
-@code{[[omp::directive(...)]]} and @code{[[omp::sequence(...)]]} in C++
-and @code{!$omp} in Fortran.  Other OpenMP directives are ignored.
+@code{[[omp::directive(...)]]}, @code{[[omp::sequence(...)]]} and
+@code{[[omp::decl(...)]]} in C++ and @code{!$omp} in Fortran.
+Other OpenMP directives are ignored.  Unless @option{-fopenmp} is
+additionally specified, the @code{loop} region binds to the current
+task region, independent of the specified @code{bind} clause.
 
 @opindex fopenmp-target-simd-clone
 @cindex OpenMP target SIMD clone

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic
  2023-09-25 18:24 [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic Tobias Burnus
@ 2023-09-26  7:34 ` Richard Biener
  2023-09-26  7:49   ` Jakub Jelinek
  2023-09-26  7:54 ` Jakub Jelinek
  1 sibling, 1 reply; 5+ messages in thread
From: Richard Biener @ 2023-09-26  7:34 UTC (permalink / raw)
  To: Tobias Burnus; +Cc: gcc-patches, Jakub Jelinek

On Mon, Sep 25, 2023 at 8:25 PM Tobias Burnus <tobias@codesourcery.com> wrote:
>
> I stumbled over this during the ARM64 talk at the cauldron as they
> consider using -fopenmp-simd by default.

Ah, forgot to ask during the talk - isn't __attribute__((simd(..))) exactly to
avoid the need for -fopenmp-simd?

> → https://gcc.gnu.org/wiki/cauldron2023 (I put my talk/BoF slides up;
> others aren't, yet)
>
> I did stumble over 'omp loop' with SIMD. It turns out that -fopenmp-simd
> just turns 'loop' into 'simd', ignoring whatever value the user has
> specified for the bind value.
>
> Additionally, [[omp::decl(...)]] was missing.
>
> Any comment to that patch before I commit it?
>
> Tobias
>
> PS: the [[omp::...]] needs a 'C++' → 'C/C++' change once omp:: support
> with C23's attributes is in.
> -----------------
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic
  2023-09-26  7:34 ` Richard Biener
@ 2023-09-26  7:49   ` Jakub Jelinek
  2023-09-26  7:50     ` Richard Biener
  0 siblings, 1 reply; 5+ messages in thread
From: Jakub Jelinek @ 2023-09-26  7:49 UTC (permalink / raw)
  To: Richard Biener; +Cc: Tobias Burnus, gcc-patches

On Tue, Sep 26, 2023 at 09:34:15AM +0200, Richard Biener wrote:
> On Mon, Sep 25, 2023 at 8:25 PM Tobias Burnus <tobias@codesourcery.com> wrote:
> >
> > I stumbled over this during the ARM64 talk at the cauldron as they
> > consider using -fopenmp-simd by default.
> 
> Ah, forgot to ask during the talk - isn't __attribute__((simd(..))) exactly to
> avoid the need for -fopenmp-simd?

Yes.  Though, -fopenmp-simd can do slightly more than that,
#pragma GCC ivdep equivalent on various loops is the other important part
(though for both simd attribute and ivdep pragma the OpenMP counterparts
are significantly more flexible, in the declare simd case one can specify
certain arguments should be linear (with various variants for
references)/uniform, simd construct can specify not just everything is
independent or not, but how many consecutive iterations must be independent,
can specify reductions etc., preferred vectorization factors, ...).
Though, I don't think it is a good idea to enable -fopenmp-simd by default.

	Jakub


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic
  2023-09-26  7:49   ` Jakub Jelinek
@ 2023-09-26  7:50     ` Richard Biener
  0 siblings, 0 replies; 5+ messages in thread
From: Richard Biener @ 2023-09-26  7:50 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Tobias Burnus, gcc-patches

On Tue, Sep 26, 2023 at 9:50 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Tue, Sep 26, 2023 at 09:34:15AM +0200, Richard Biener wrote:
> > On Mon, Sep 25, 2023 at 8:25 PM Tobias Burnus <tobias@codesourcery.com> wrote:
> > >
> > > I stumbled over this during the ARM64 talk at the cauldron as they
> > > consider using -fopenmp-simd by default.
> >
> > Ah, forgot to ask during the talk - isn't __attribute__((simd(..))) exactly to
> > avoid the need for -fopenmp-simd?
>
> Yes.  Though, -fopenmp-simd can do slightly more than that,
> #pragma GCC ivdep equivalent on various loops is the other important part
> (though for both simd attribute and ivdep pragma the OpenMP counterparts
> are significantly more flexible, in the declare simd case one can specify
> certain arguments should be linear (with various variants for
> references)/uniform, simd construct can specify not just everything is
> independent or not, but how many consecutive iterations must be independent,
> can specify reductions etc., preferred vectorization factors, ...).
> Though, I don't think it is a good idea to enable -fopenmp-simd by default.

Yeah, writing invalid OMP simd pragmas (syntactically or semantically) shouldn't
be causing problems when not using -fopenmp-simd but would if that's
the default.

Richard.

>
>         Jakub
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic
  2023-09-25 18:24 [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic Tobias Burnus
  2023-09-26  7:34 ` Richard Biener
@ 2023-09-26  7:54 ` Jakub Jelinek
  1 sibling, 0 replies; 5+ messages in thread
From: Jakub Jelinek @ 2023-09-26  7:54 UTC (permalink / raw)
  To: Tobias Burnus; +Cc: gcc-patches

On Mon, Sep 25, 2023 at 08:24:14PM +0200, Tobias Burnus wrote:
> I stumbled over this during the ARM64 talk at the cauldron as they
> consider using -fopenmp-simd by default.
> 
> → https://gcc.gnu.org/wiki/cauldron2023 (I put my talk/BoF slides up;
> others aren't, yet)
> 
> I did stumble over 'omp loop' with SIMD. It turns out that -fopenmp-simd
> just turns 'loop' into 'simd', ignoring whatever value the user has
> specified for the bind value.

I think that is desirable, because with -fopenmp-simd binding to teams,
parallel and thread are the same thing, there is exactly one team and
one thread in parallel.  Sure, one can have multiple threads with
-fopenmp-simd, but those are POSIX threads, while the binding of loop is
to the OpenMP constructs.
Even loop binds(team) is a way to express the iterations are vectorizable...

	Jakub


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-09-26  7:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-25 18:24 [patch] invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic Tobias Burnus
2023-09-26  7:34 ` Richard Biener
2023-09-26  7:49   ` Jakub Jelinek
2023-09-26  7:50     ` Richard Biener
2023-09-26  7:54 ` Jakub Jelinek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).