diff mbox series

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

Message ID c456c0a8-def8-4737-b884-a758b1156136@codesourcery.com
State New
Headers show
Series invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop semantic | expand

Commit Message

Tobias Burnus Sept. 25, 2023, 6:24 p.m. UTC 
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

Comments

Richard Biener Sept. 26, 2023, 7:34 a.m. UTC | #1 
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
Jakub Jelinek Sept. 26, 2023, 7:49 a.m. UTC | #2 
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
Richard Biener Sept. 26, 2023, 7:50 a.m. UTC | #3 
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
>
Jakub Jelinek Sept. 26, 2023, 7:54 a.m. UTC | #4 
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
diff mbox series

Patch

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