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

[Hal Finkel]

----- Original Message -----
> From: "andreybokhanko" <andreybokhanko at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Michael Wong" <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at gmx.com>, "cfe-dev" <cfe-dev at cs.uiuc.edu>,
> "<openmp-dev at dcs-maillist2.engr.illinois.edu>" <openmp-dev at 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

> 
> Yours,
> Andrey
> 
> > 19 мая 2015 г., в 0:26, Hal Finkel <hfinkel at anl.gov> написал(а):
> > 
> > ----- Original Message -----
> >> From: "Andrey Bokhanko" <andreybokhanko at gmail.com>
> >> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>,
> >> openmp-dev at dcs-maillist2.engr.illinois.edu
> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Michael Wong"
> >> <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at 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
> > 
> >> 
> >> Yours,
> >> Andrey Bokhanko
> >> ==============
> >> Software Engineer
> >> Intel Compiler Team
> >> Intel
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory