Developer Guide and Reference

Contents

User-Mandated or SIMD Vectorization

User-mandated or SIMD vectorization supplements automatic vectorization
just like OpenMP* parallelization
supplements automatic parallelization. The following figure illustrates this relationship. User-mandated vectorization is implemented as a single-instruction-multiple-data (SIMD) feature and is referred to as SIMD vectorization.
The SIMD vectorization feature is available for both Intel® microprocessors and non-Intel microprocessors. Vectorization may call library routines that can result in additional performance gain on Intel® microprocessors than on non-Intel microprocessors.
The following figure illustrates how SIMD vectorization is positioned among various approaches that you can take to generate vector code that exploits vector hardware capabilities. The programs written with SIMD vectorization are very similar to those written using auto-vectorization hints. You can use SIMD vectorization to minimize the amount of code changes that you may have to go through in order to obtain vectorized code.
SIMD vectorization uses the
#pragma omp simd
pragma
to effect loop vectorization.
Consider an example in C++ where the function
add_floats()
uses too many unknown pointers for the compiler’s automatic runtime independence check optimization to kick in. You can give a data dependence assertion using the auto-vectorization hint via
#pragma ivdep
and let the compiler decide whether the auto-vectorization optimization should be applied to the loop. Or you can now enforce vectorization of this loop by using
#pragma omp simd
.
The one big difference between using
#pragma omp simd
and auto-vectorization hints is that with
#pragma omp simd
, the compiler generates a warning when it is unable to vectorize the loop. With auto-vectorization hints, actual vectorization is still under the discretion of the compiler, even when you use the
#pragma vector always
hint.
#pragma omp simd
has optional clauses to guide the compiler on how vectorization must proceed. Use these clauses appropriately so that the compiler obtains enough information to generate correct vector code. For more information on the clauses, see the
#pragma omp simd
description.

Additional Semantics

Note the following points when using the
omp simd pragma
.
  • A variable may belong to zero or one of the following: private, linear, or reduction.
  • Within the vector loop, an expression is evaluated as a vector value if it is private, linear, reduction, or it has a sub-expression that is evaluated to a vector value. Otherwise, it is evaluated as a scalar value (that is, broadcast the same value to all iterations). Scalar value does not necessarily mean loop invariant, although that is the most frequently seen usage pattern of scalar value.
  • A vector value may not be assigned to a scalar L-value. It is an error.
  • A scalar L-value may not be assigned under a vector condition. It is an error.
  • The
    switch
    statement is not supported.
You may find it difficult to describe vector semantics using the SIMD pragma for some auto-vectorizable loops. One example is
MIN
/
MAX
reduction in C since the language does not have
MIN
/
MAX
operators.

Restrictions on Using
a #pragma omp declare simd
declaration

Vectorization depends on two major factors: hardware and the style of source code. When using the vector declaration, the following features are not allowed:
  • Thread creation and joining through
    , OpenMP*
    parallel
    /
    for
    /
    sections
    /
    task
    /
    target
    /
    teams
    , and explicit threading API calls.
  • Locks, barriers, atomic construct, critical sections (These are allowed inside
    #pragma omp ordered simd
    blocks).
  • Inline ASM code, VM and Vector Intrinsics (for example, SVML intrinsics).
  • Using setjmp, longjmp, SHE and computed
    GOTO
    .
  • EH is not allowed and all vector functions are considered noexcept.
  • The
    switch
    statement (in some cases this may be supported and converted to
    if
    statements, but this is not reliable).
  • The
    exit()
    /
    abort()
    calls.
Non-vector function calls are generally allowed within vector functions but calls to such functions are serialized lane-by-lane and so might perform poorly. Also for SIMD-enabled functions it is not allowed to have side effects except writes by their arguments. This rule can be violated by non-vector function calls, so be careful executing such calls in SIMD-enabled functions.
Formal parameters must be of the following data types:
  • (un)signed 8, 16, 32, or 64-bit integer
  • 32- or 64-bit floating point
  • 64- or 128-bit complex
  • A pointer (C++ reference is considered a pointer data type)

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.