The compiler cannot statically detect the trip count. To fix: Identify the expected number of iterations using a directive: .
Example: Read More:

• LOOP COUNT
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

The trip count after loop unrolling is too small compared to the vector length. To fix: Prevent loop unrolling or decrease the unroll factor using a directive: or .
Example: disable loop unrolling Read More:

• UNROLL and NOUNROLL
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

The compiler chose a vector length, but the trip count might be smaller than that vector length. To fix: Specify a smaller vector length using a directive: .
Example: Specify vector length using Read More:

• SIMD Loop Directive
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

One of the memory accesses in the source loop does not start at an optimally aligned address boundary. To fix: Align the data and tell the compiler the data is aligned. To align data, use . To tell the compiler the data is aligned, use before the source loop.
Read More:

• Data Alignment to Assist Vectorization
• Vectorization Resources for Intel® Advisor Users

The trip count is not a multiple of vector length. To fix: Do one of the following:

• Increase the size of objects and add iterations so the trip count is a multiple of vector length.
• Increase the size of static and automatic objects, and use a compiler option to add data padding.

Windows* OS	Linux* OS
/Qopt-assume-safe-padding	-qopt-assume-safe-padding

Note: These compiler options apply only to Intel® Many Integrated Core Architecture (Intel® MIC Architecture). Option is the replacement compiler option for , which is deprecated.

When you use one of these compiler options, the compiler does not add any padding for static and automatic objects. Instead, it assumes that code can access up to 64 bytes beyond the end of the object, wherever the object appears in your application. To satisfy this assumption, you must increase the size of static and automatic objects in your application.

Optional: Specify the trip count, if it is not constant, using a directive:
Read More:

• qopt-assume-safe-padding, Qopt-assume-safe-padding; LOOP COUNT
• Utilizing Full Vectors and Use of Option -qopt-assume-safe-padding, Getting Started with Intel Compiler Pragmas and Directives, and Vectorization Resources for Intel® Advisor Users

The Survey Report lacks trip counts data that might generate more precise recommendations. To fix: Run a Trip Counts analysis.

The compiler did not vectorize the remainder loop, even though doing so could improve performance. To fix: Force vectorization using a directive: or .
Example: Force the compiler to vectorize the remainder loop using Read More:

• SIMD Loop Directive, VECTOR and NOVECTOR
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

The source loop contains data types of different widths. To fix: Use the smallest data type that gives the needed precision to use the entire vector register width.
Example: If only 16-bits are needed, using a short rather than an int can make the difference between eight-way or four-way SIMD parallelism, respectively.

Inlining of user-defined functions is disabled by compiler option. To fix: When using the or compiler option to control inline expansion, replace the argument with the argument to enable inlining when an keyword or attribute is specified or the argument to enable inlining of any function at compiler discretion.

Windows* OS	Linux* OS
Ob1 or Ob2	-inline-level=1 or -inline-level=2

Read More:

• inline-level, Ob
• Vectorization Resources for Intel® Advisor Users

Some user-defined function(s) are not vectorized or inlined by the compiler. To fix: Do one of the following:

• Enforce vectorization of the source loop by means of SIMD instructions and/or create a SIMD version of the function(s) using a directive:

  Target	Directive
  Source loop	!DIR$ SIMD or !$OMP SIMD
  Inner function definition or declaration	!$OMP DECLARE SIMD

• If using the
  Ob
  or
  inline-level
  compiler option to control inline expansion with the
  1
  argument, use an
  inline
  keyword to enable inlining or replace the
  1
  argument with
  2
  to enable inlining of any function at compiler discretion.

Example: Read More:

• DECLARE SIMD, SIMD Directive (OpenMP* API), SIMD Loop Directive
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

Passing an array/array section to an function/subroutine is creating a dependency that prevents vectorization. To fix:

• Enforce vectorization of the source loop using SIMD instructions and/or create a SIMD version of the function(s) using a directive:

  Target	Directive
  Source loop	!DIR$ SIMD or !$OMP SIMD
  Inner function definition or declaration	!$OMP DECLARE SIMD

• Call from a
  DO
  loop.
  

Example:
Original code: Revised code: Read More:

• DECLARE SIMD, SIMD Directive (OpenMP* API), SIMD Loop Directive
• Explicit Vector Programming in Fortran, Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

Inlining of user-defined functions is disabled by compiler option. To fix: When using the or compiler option to control inline expansion, replace the argument with the argument to enable inlining when an keyword or attribute is specified or the argument to enable inlining of any function at compiler discretion.

Windows* OS	Linux* OS
Ob1 or Ob2	-inline-level=1 or -inline-level=2

Read More:

• inline-level, Ob
• Vectorization Resources for Intel® Advisor Users

Some user-defined function(s) are not vectorized or inlined by the compiler. To fix: Do one of the following:

• Enforce vectorization of the source loop by means of SIMD instructions and/or create a SIMD version of the function(s) using a directive:

  Target	Directive
  Source loop	!DIR$ SIMD or !$OMP SIMD
  Inner function definition or declaration	!$OMP DECLARE SIMD

• If using the
  Ob
  or
  inline-level
  compiler option to control inline expansion with the
  1
  argument, use an
  inline
  keyword to enable inlining or replace the
  1
  argument with
  2
  to enable inlining of any function at compiler discretion.

Example: Read More:

• DECLARE SIMD, SIMD Directive (OpenMP* API), SIMD Loop Directive
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

Inlining is disabled by compiler option. To fix: When using the or compiler option to control inline expansion, replace the argument with the argument to enable inlining when an keyword or attribute is specified or the argument to enable inlining of any function at compiler discretion.

Windows* OS	Linux* OS
Ob1 or Ob2	-inline-level=1 or -inline-level=2

Read More:

• inline-level, Ob
• Vectorization Resources for Intel® Advisor Users

Your application calls scalar instead of vectorized versions of math functions. To fix: Do all of the following:

• Use the
  -mveclibabi=svml
  compiler option to specify the Intel short vector math library ABI type for vector instrinsics.
• Use the
  -ftree-vectorize
  and
  -funsafe-math-optimizations
  compiler options to enable vector math functions.
• Use the
  -L/path/to/intel/lib
  and
  -lsvml
  compiler options to specify an SVML ABI-compatible library at link time.

Example:
Read More:

• The GNU Fortran Compiler
• Vectorization Resources for Intel® Advisor Users

Your application calls scalar instead of vectorized versions of math functions. To fix: Do all of the following:

• Upgrade the Glibc library to version 2.22 or higher. It supports SIMD directives in OpenMP* 4.0 or higher.
• Upgrade the GNU* gfortran compiler to version 4.9 or higher. It supports vectorized math function options.
• Use the
  -fopenmp
  and
  -ffast-math
  compiler options to enable vector math functions.
• Use appropriate OpenMP SIMD directives to enable vectorization.

Note: Also use the and compiler options if you have multiple Glibc libraries installed on the host.
Example:
Read More:

• Glibc wiki/Libmvec
• Vectorization Resources for Intel® Advisor Users

Your application calls serialized versions of math functions when you use the floating point model. To fix: Do one of the following:

• Add
  fast-transcendentals
  compiler option to replace calls to transcendental functions with faster calls.

  Windows* OS	Linux* OS
  /Qfast-transcendentals	-fast-transcendentals

  CAUTION: This may reduce floating point accuracy.
• Enforce vectorization of the source loop using a directive:
  !DIR$ SIMD
  or
  !$OMP SIMD

Example: Read More:

• fast-transcentals, Qfast-transcendentals; SIMD Directive (OpenMP* API); SIMD Loop Directive
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

Your application calls serialized versions of math functions when you use the floating point model. To fix: Do one of the following:

• Use the
  fast
  floating point model to enable more aggressive optimizations or the
  precise
  floating point model to disable optimizations that are not value-safe on fast transcendental functions.

  Windows* OS	Linux* OS
  /fp:fast	-fp-model fast
  /fp:precise /Qfast-transcendentals	-fp-model precise -fast-transcendentals

  CAUTION: This may reduce floating point accuracy.
• Use the
  precise
  floating point model and enforce vectorization of the source loop using a directive:
  !DIR$ SIMD
  or
  !$OMP SIMD

Example: Read More:

• fast-transcendentals, Qfast-transcendentals; fp-model, fp; SIMD Directive (OpenMP* API); SIMD Loop Directive
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

Typically system function or subroutine calls cannot be vectorized; even a print statement is sufficient to prevent vectorization. To fix: Avoid using system function calls in loops.

OpenMP calls prevent automatic vectorization when the compiler cannot move the calls outside the loop body, such as when OpenMP calls are not invariant. To fix:

1. Split the OpenMP parallel loop section into two using directives.

   Target	Directive
   Outer section	!$OMP PARALLEL SECTIONS
   Inner section	!$OMP DO NOWAIT

2. Move the OpenMP calls outside the loop when possible.

Example:
Original code: Revised code: Read More:

• NOWAIT Clause, PARALLEL SECTIONS
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor XE Users

Locking objects slows loop execution. To fix: Rewrite the code without OpenMP lock functions. For example, allocating separate arrays for each thread and then merging them after a parallel section may improve speed (but consume more memory).
Read More:

• Calling Functions on the CPU to Modify the Coprocessor’s Execution Environment, Lock Routines section in  OpenMP Run-time Library Routines, PARALLEL SECTIONS
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor XE Users

Indirect function or subroutine calls cannot be vectorized. To fix: Avoid using indirect calls in loops.

For 64-bit applications, branch prediction performance can be negatively impacted when the branch target is more than 4 GB away from the branch. This is more likely to happen when the application is split into shared libraries. To fix: Do the following:

• Upgrade the Glibc library to version 2.23 or higher.
• Set environment variable
  export LD_PREFER_MAP_32BIT_EXEC=1
  .

Read More:

• Glibc 2.23 release notes and libc bug report 19367: Improve branch prediction
• Vectorization Resources for Intel® Advisor Users

There is no confirmation that a real (proven) dependency is present in the loop. To confirm: Run a Dependencies analysis.

The Dependencies analysis shows there is a real (proven) dependency in the loop. To fix: Do one of the following:

• If there is an anti-dependency, enable vectorization using the directive
  !$OMP SIMD SAFELEN(length)
  , where
  length
  is smaller than the distance between dependent iterations in anti-dependency. For example:
  !$OMP SIMD SAFELEN(4) do i = 1, N-4, 4 a(i+4) = b(i) * c enddo
• If there is a reduction pattern dependency in the loop, enable vectorization using the directive
  !$OMP SIMD REDUCTION(operator:list)
  . For example:
  !$OMP SIMD REDUCTION(+:SUMX) do k = 1, size2 sumx = sumx + x(k) * b(k) enddo
• Rewrite the code to remove the dependency. Use programming techniques such as variable privatization.

Read More:

• SIMD Directive (OpenMP* API)
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

The Dependencies analysis shows there is no real dependency in the loop for the given workload. Tell the compiler it is safe to vectorize using the keyword or a directive:

Directive	Outcome
!DIR$ SIMD or !$OMP SIMD	Ignores all dependencies in the loop
!DIR$ IVDEP	Ignores only vector dependencies (which is safest)

Example: Read More:

• IVDEP, SIMD Directive (OpenMP* API), SIMD Loop Directive
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

The current directive unroll factor increases vector register pressure. To fix: Decrease unroll factor using a directive: or
Example: Read More:

• UNROLL and NOUNROLL
• Getting Started with Intel Compiler Pragmas and Directives and Vectorization Resources for Intel® Advisor Users

Possible register spilling along with high vector register pressure is preventing effective vectorization. To fix: Use the directive or rewrite your code to distribute the source loop. This can decrease register pressure as well as enable software pipelining and improve both instruction and data cache use.
Example: Read More:

• DISTRIBUTE POINT
• 3D Finite Differences on Multi-core Processors, Getting Started with Intel Compiler Pragmas and Directives, and Vectorization Resources for Intel® Advisor Users

There is no confirmation inefficient memory access patterns are present. To confirm: Run a Memory Access Patterns analysis.

An array is the most common type of data structure containing a contiguous collection of data items that can be accessed by an ordinal index. You can organize this data as an array of structures (AoS) or as a structure of arrays (SoA). While AoS organization is excellent for encapsulation, it can hinder effective vector processing. To fix: Rewrite code to organize data using SoA instead of AoS.
Read More:

• Programming Guidelines for Vectorization
• Case study: Comparing Arrays of Structures and Structures of Arrays Data Layouts for a Compute-Intensive Loop and Vectorization Resources for Intel® Advisor Users

This loop may has less efficient memory access patterns than a nearby outer loop. To fix: Run a Memory Access Patterns analysis on the outer loop. If the memory access patterns are more efficient for the outer loop, reorder the loops if possible.

The loop is multi-versioned for unit and non-unit strides in assumed-shape arrays or pointers, but marked versions of the loop have unit stride access only. The CONTIGUOUS attribute specifies the target of a pointer or an assumed-shape array is contiguous. It can make it easier to enable optimizations that rely on the memory layout of an object occupying a contiguous block of memory. Note: The results are indeterminate and could result in wrong answers and segmentation faults if the user assertion is wrong and the data is not contiguous at runtime.
Example: Read More:

• CONTIGUOUS
• Fortran Array Data and Arguments and Vectorization and Vectorization Resources for Intel® Advisor Users

Although static analysis presumes the loop may benefit from FMA instructions available with the AVX2 ISA, no AVX2-specific code executed for this loop. To fix: Use the compiler option to generate AVX2-specific code, or the compiler option to enable multiple, feature-specific, auto-dispatch code generation, including AVX2.

Windows* OS	Linux* OS
/QxCORE-AVX2 or /QaxCORE-AVX2	-xCORE-AVX2 or -axCORE-AVX2

Read More:

• ax, Qax; x, Qx
• Code Generation Options in the Intel® Fortran Compiler 17.0 User and Reference Guide
• Compiling for the Intel® Xeon Phi™ processor x200 and the Intel® AVX-512 ISA and Vectorization Resources for Intel® Advisor Users

Although static analysis presumes the loop may benefit from FMA instructions available with the AVX2 ISA, no AVX2-specific code executed for this loop. To fix: Instead of using the compiler option, which limits optimization opportunities by the host ISA, use the compiler option to compile for machines with and without AVX2 support, or the compiler option to compile for machines with AVX2 support only.

Windows* OS	Linux* OS
/QxCORE-AVX2 or /QaxCORE-AVX2	-xCORE-AVX2 or -axCORE-AVX2

Read More:

• ax, Qax; x, Qx
• Code Generation Options in the Intel® Fortran Compiler 17.0 User and Reference Guide
• Compiling for the Intel® Xeon Phi™ processor x200 and the Intel® AVX-512 ISA and Vectorization Resources for Intel® Advisor Users

Static analysis presumes the loop may benefit from FMA instructions available with the AVX2 ISA, but the floating-point model disables FMA instruction generation by default. To fix: Override this behavior using the compiler option.

Windows* OS	Linux* OS
/Qfma	-fma

Read More:

• fma, Qfma
• Floating-Point Operations and Code Generation Options in the Intel® Fortran Compiler 17.0 User and Reference Guide
• Vectorization Resources for Intel® Advisor Users

The loop contains FMA instructions (so vectorization could be beneficial) but is not vectorized. To fix: Review corresponding compiler diagnostics to check if vectorization enforcement is possible and profitable.
Read More:

• Vectorization Resources for Intel® Advisor Users

The default instruction set architecture (ISA) for SIMD-enabled functions is inefficient for your host processor because it could result in extra memory operations between registers. To fix: Add a PROCESSOR clause to your vector declaration. Specifically, add to your directive.
Read More:

• DECLARE SIMD, PROCESSOR Clause
• Vectorization Resources for Intel® Advisor Users

In Fortran applications, by default, scalar arguments are passed by reference. Therefore, in SIMD-enabled functions, arguments are passed as a short vector of addresses instead of a single address. The compiler then gathers data from the vector of addresses to create a short vector of values for use in subsequent vector arithmetic. This gather activity negatively impacts performance. To fix: Add a LINEAR clause with a REF modifier (introduced in OpenMP* 4.5) to your vector declaration. Specifically, add to your directive.
Read More:

• DECLARE SIMD, LINEAR Clause
• Vectorization Resources for Intel® Advisor Users

The Memory Access Patterns Report shows the following regular stride access(es):

Variable	Pattern
block 0x19fa8866040 allocated at example.cpp:14	Uniform (Horizontal Invariant)

See details in the Memory Access Patterns Report Source Details view.

To improve memory access: Use the compiler option to enable interprocedural optimization (IPO) between files, and refactor your code to alert the compiler to a regular stride access.

Read More:

• ipo, Qipo
• Vectorization Resources for Intel® Advisor Users

Static analysis presumes the loop may benefit from AVX-512 approximate reciprocal instructions, but these instructions were not used. To fix: Use one of the following compiler options:

• xCOMMON-AVX512
  - tells the compiler which processor features to target, including instructions sets and optimizations it may generate, including AVX-512.
• axCOMMON-AVX512
  - tells the compiler to generate multiple, feature-specific, auto-dispatch code for Intel processors if there is a performance benefit.

Windows* OS	Linux* OS
/QxCOMMON-AVX512 or /QaxCOMMON-AVX512	-xCOMMON-AVX512 or -axCOMMON-AVX512

Read More:

• ax, Qax; x, Qx
• Code Generation Options in the Intel® Fortran Compiler 17.0 User and Reference Guide
• Compiling for the Intel® Xeon Phi™ processor x200 and the Intel® AVX-512 ISA and Vectorization Resources for Intel® Advisor Users

Static analysis presumes the loop may benefit from AVX-512 Exponential and Reciprocal (AVX-512ER) instructions currently supported only on Intel® Xeon Phi™ processors, but these instructions were not used. To fix: Use one of the following compiler options:

• xMIC-AVX512
  - tells the compiler which processor features to target, including instructions sets and optimizations it may generate, including AVX-512ER.
• axMIC-AVX512
  - tells the compiler to generate multiple, feature-specific, auto-dispatch code for Intel processors if there is a performance benefit.

Windows* OS	Linux* OS
/QxMIC-AVX512 or /QaxMIC-AVX512	-xMIC-AVX512 or -axMIC-AVX512

Read More:

• ax, Qax; x, Qx
• Code Generation Options in the Intel® Fortran Compiler 17.0 User and Reference Guide
• Compiling for the Intel® Xeon Phi™ processor x200 and the Intel® AVX-512 ISA and Vectorization Resources for Intel® Advisor Users

Static analysis presumes the loop may benefit from using approximate reciprocal instructions, but the precision and floating-point model settings may prevent the compiler from using these instructions. To fix: Fine-tune your usage of the following compiler options:

Windows* OS	Linux* OS	Comment
/fp	-fp-model	-fp-model=precise prevents the use of approximate reciprocal instructions.
/Qimf-precision	-fimf-precision	Consider using -fimf-precision=medium or -fimf-precision=low .
/Qimf-accuracy-bits	-fimf-accuracy-bits	Consider decreasing this setting.
/Qimf-max-error	-fimf-max-error	Consider increasing this setting. There is a similar option: -fimf-absolute-error . Avoid using both options at the same time or tune them together.
/Qimf-absolute-error	-fimf-absolute-error	Consider using -fimf-max-error instead and set -fimf-absolute-error=0 (default) or increase this setting together with -fimf-max-error .
/Qimf-domain-exclusion	-fimf-domain-exclusion	Consider increasing this setting. More excluded classes enable more optimized code. USE WITH CAUTION. This option may cause incorrect behavior if your calculations involve excluded domains.
/Qimf-arch-consistency	-fimf-arch-consistency	-fimf-arch-consistency=true may prevent the use of approximate reciprocal instructions.
/Qprec-div	-prec-div	-prec-div prevents the use of approximate reciprocal instructions.
/Qprec-sqrt	-prec-sqrt	-prec-sqrt prevents the use of approximate reciprocal instructions.

Read More:

• Floating-Point Operations and Floating-Point Options in the Intel® Fortran Compiler 17.0 User and Reference Guide
• Vectorization Resources for Intel® Advisor Users