[cfe-dev] Option to control level of OpenMP support

[Sean Silva]

On Thu, May 7, 2015 at 4:55 AM, Andrey Bokhanko <andreybokhanko at gmail.com>
wrote:

> 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


>
> Personally, I believe option 2) is much more convenient for end users.
>
> Opinions? (Both on what is preferable and option name.)
>
> Yours,
> Andrey Bokhanko
> ==============
> Software Engineer
> Intel Compiler Team
> Intel
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150519/14b9420c/attachment.html>