Option to control level of OpenMP support

All,

Now, with OpenMP 3.1 support completed
(http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/042845.html) we
(Intel) plan to go on with implementing 4.0 support. Others plan to
contribute as well -- AFAIK, at least IBM has specific plans and some
code already implemented.

However, there is no chance for us to have OpenMP 4.0 completed in
time for next release. And in general, it is next to impossible to
sync state of the next OpenMP standard support with be-annual releases
-- invariably we will have something only partially implemented (with
some pragmas working in full, some analyzed (with errors reported) but
no actual LLVM IR generated, some not supported at all) at any given
release time.

We can deal with this in two ways:
1) Enable all new developments by default, just document in release
notes that support of OpenMP x.x version is guaranteed, but everything
else is "experimental".
2) Enable only completed standard (3.1 at the moment) by default, and
let users enable non-completed support with an option. Say,
-std-openmp=n.

Personally, I believe option 2) is much more convenient for end users.

Opinions? (Both on what is preferable and option name.)

Yours,
Andrey Bokhanko

A third way would be to warn about new features. Kind of like the C++11
warnings.

Joerg

Yep, it is a possibility -- but unfortunately, ill suited for OpenMP.

First, due to development model: Sema and CodeGen parts of offloading
(the single biggest OMP 4.0 "feature") will be implemented by separate
groups of people. Alexey Bataev (Intel) will handle Sema, since he is
most experienced with OpenMP implementation in clang, while CodeGen
will be implemented by good folks from IBM. CodeGen for offloading is
HUGE, so Sema will likely be completed way in advance of CodeGen, so
even with a warning message clang will still fail (in CodeGen) for any
offloading-related pragma.

Second, due to the nature of OpenMP language. In C++11 each new
feature is relatively self-contained, so they can be implemented one
after another. Offloading consists of several pragmas, clauses and
combinations of them (see
http://openmp.org/mp-documents/OpenMP-4.0-C.pdf for details). To have
some of these pragmas / clauses fully implemented (with no warnings
printed), while others not implemented / partially implemented (with
warnings printed) means partial implementation of offloading and even
more confusion to end users.

Andrey

From: "Andrey Bokhanko" <andreybokhanko@gmail.com>
To: "cfe-dev" <cfe-dev@cs.uiuc.edu>, openmp-dev@dcs-maillist2.engr.illinois.edu
Cc: "Hal Finkel" <hfinkel@anl.gov>, "Michael Wong" <fraggamuffin@gmail.com>, "Alexey Bataev" <a.bataev@gmx.com>
Sent: Thursday, May 7, 2015 6:55:08 AM
Subject: Option to control level of OpenMP support

All,

Now, with OpenMP 3.1 support completed
(http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/042845.html) we
(Intel) plan to go on with implementing 4.0 support. Others plan to
contribute as well -- AFAIK, at least IBM has specific plans and some
code already implemented.

However, there is no chance for us to have OpenMP 4.0 completed in
time for next release. And in general, it is next to impossible to
sync state of the next OpenMP standard support with be-annual
releases
-- invariably we will have something only partially implemented (with
some pragmas working in full, some analyzed (with errors reported)
but
no actual LLVM IR generated, some not supported at all) at any given
release time.

We can deal with this in two ways:
1) Enable all new developments by default, just document in release
notes that support of OpenMP x.x version is guaranteed, but
everything
else is "experimental".
2) Enable only completed standard (3.1 at the moment) by default, and
let users enable non-completed support with an option. Say,
-std-openmp=n.

Personally, I believe option 2) is much more convenient for end
users.

Opinions? (Both on what is preferable and option name.)

I think that we should, by default, enable all available OpenMP features. Specifically, even though we don't have OpenMP 4 support complete yet, having the 'simd' directives available will be really nice. However, we must only set the value of _OPENMP based on the latest standard for which we have complete support. Having an -std-openmp=<n> will also be a nice feature, allowing us to actually restrict the available functionality to the standard level provided. We can default to "whatever you have", but if the user requests a particular version, only provide features from that version (and, thus, set _OPENMP accordingly).

-Hal

My personal preference is to err on conservative side (by enabling by default only what is completely implemented), but what Hal proposed is fine as well.

And yes -- enabling pragma simd by default would be absolutely reasonable. Especially given that everything but a couple of clauses is complete and work fine.

Yours,
Andrey

From: "andreybokhanko" <andreybokhanko@gmail.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Michael Wong" <fraggamuffin@gmail.com>, "Alexey Bataev" <a.bataev@gmx.com>, "cfe-dev" <cfe-dev@cs.uiuc.edu>,
"<openmp-dev@dcs-maillist2.engr.illinois.edu>" <openmp-dev@dcs-maillist2.engr.illinois.edu>
Sent: Tuesday, May 19, 2015 11:26:47 AM
Subject: Re: Option to control level of OpenMP support

My personal preference is to err on conservative side (by enabling by
default only what is completely implemented), but what Hal proposed
is fine as well.

And yes -- enabling pragma simd by default would be absolutely
reasonable. Especially given that everything but a couple of clauses
is complete and work fine.

Maybe we should define a pseudo-standard mode called 3.1+simd (which is OpenMP 3.1 plus the simd features from 4.0) and let that be the default.

-Hal

All,

Now, with OpenMP 3.1 support completed
(http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/042845.html) we
(Intel) plan to go on with implementing 4.0 support. Others plan to
contribute as well -- AFAIK, at least IBM has specific plans and some
code already implemented.

However, there is no chance for us to have OpenMP 4.0 completed in
time for next release. And in general, it is next to impossible to
sync state of the next OpenMP standard support with be-annual releases
-- invariably we will have something only partially implemented (with
some pragmas working in full, some analyzed (with errors reported) but
no actual LLVM IR generated, some not supported at all) at any given
release time.

We can deal with this in two ways:
1) Enable all new developments by default, just document in release
notes that support of OpenMP x.x version is guaranteed, but everything
else is "experimental".

This makes a lot of sense to me. Maybe we could just have a piece of
user-level documentation docs/OpenMPSupport.rst which lists the current
support level for different things (granularity doesn't need to be openmp
versions, e.g. simd might be an individual thing). These will naturally get
bundled into each release's documentation and will indicate the current
level of support for that release.

2) Enable only completed standard (3.1 at the moment) by default, and
let users enable non-completed support with an option. Say,
-std-openmp=n.

It doesn't really make sense to add a user-visible flag to control
something that is just an implementation/development detail (how far along
we are with each version of the standard). In particular, having a
-std-openmp=n flag implies having a default for that flag; changing
defaults for flags that have user-visible effects is nasty. It might make
sense to add a -std-openmp=n flag in the case where different versions are
conflicting in some (usually small, but definitely conflicting) way, the
way we do for -std=.

-- Sean Silva