You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a OpenMP SIMD loop, an ordered construct signals that the contents of the construct should be run in order, and not vectorized.
Therefore, if a SIMD loop is written with an ordered construct to preserve correctness, we should only indicate that OpenMP SIMD pragma be used if the ordered construct is also available.
Right now that is not the case. We currently use in a few places like this_ONEDPL_PRAGMA_SIMD_ORDERED_MONOTONIC. However, the monotonic clause is an ICC specific optimization which is not part of the OpenMP spec, and is ignored currently by IntelLLVM and other compilers.
IntelLLVM fully supports OpenMP 4.5 as of 2021.1 (including the SIMD loop ordered construct). However, we currently enable or disable _ONEDPL_PRAGMA_SIMD_ORDERED_MONOTONIC... based upon the availability of monotonic, not based on the availability of ordered. This results in a SIMD loop without the ordered construct should be needed for correctness.
I believe we do not see correctness issues because the compiler detects loop dependencies and refuses to vectorize the loops, but we should still fix the problem to not request a SIMD loop when an ordered construct is unavailable.
My proposed fix is to separate support for the ordered construct from ordered monotonic, and make the later depend on the former. Additionally, because we have some support for #pragma simd without OpenMP, we should connect SIMD pragmas which require an ordered construct to the availability of ordered.
Adding and utilizing the following macros should resolve the issue: _ONEDPL_PRAGMA_SIMD_ORDERED(...) which provides _ONEDPL_PRAGMA(omp ordered simd ##__VA_ARGS__) when available _ONEDPL_PRAGMA_SIMD_WITH_ORDERED which provides _ONEDPL_PRAGMA(omp simd), but only when ordered is also supported.
(variable number of args are to allow clauses like monotonic to be added to ordered constructs where applicable)
The text was updated successfully, but these errors were encountered:
In a OpenMP
SIMD
loop, anordered
construct signals that the contents of the construct should be run in order, and not vectorized.Therefore, if a
SIMD
loop is written with anordered
construct to preserve correctness, we should only indicate that OpenMPSIMD
pragma be used if theordered
construct is also available.Right now that is not the case. We currently use in a few places like this
_ONEDPL_PRAGMA_SIMD_ORDERED_MONOTONIC
. However, themonotonic
clause is an ICC specific optimization which is not part of the OpenMP spec, and is ignored currently by IntelLLVM and other compilers.IntelLLVM fully supports OpenMP 4.5 as of 2021.1 (including the
SIMD
loopordered
construct). However, we currently enable or disable_ONEDPL_PRAGMA_SIMD_ORDERED_MONOTONIC...
based upon the availability ofmonotonic
, not based on the availability ofordered
. This results in aSIMD
loop without theordered
construct should be needed for correctness.I believe we do not see correctness issues because the compiler detects loop dependencies and refuses to vectorize the loops, but we should still fix the problem to not request a
SIMD
loop when anordered
construct is unavailable.My proposed fix is to separate support for the
ordered
construct fromordered monotonic
, and make the later depend on the former. Additionally, because we have some support for#pragma simd
without OpenMP, we should connectSIMD
pragmas which require anordered
construct to the availability ofordered
.Adding and utilizing the following macros should resolve the issue:
_ONEDPL_PRAGMA_SIMD_ORDERED(...)
which provides_ONEDPL_PRAGMA(omp ordered simd ##__VA_ARGS__)
when available_ONEDPL_PRAGMA_SIMD_WITH_ORDERED
which provides_ONEDPL_PRAGMA(omp simd)
, but only whenordered
is also supported.(variable number of args are to allow clauses like
monotonic
to be added toordered
constructs where applicable)The text was updated successfully, but these errors were encountered: