[Openmp-dev] Option to control level of OpenMP support
andreybokhanko
andreybokhanko at gmail.com
Tue May 19 09:26:47 PDT 2015
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
> 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
More information about the Openmp-dev
mailing list