Utilizing Full Vectors and Use of Option -qopt-assume-safe-padding

Compiler Methodology for Intel® MIC Architecture

Vectorization Essentials, Utilizing Full Vectors and Use of Option -qopt-assume-safe-padding

Efficient vectorization involves making full use of the vector-hardware. This implies that users should strive to get most code to be executed in the kernel-vector loop as opposed to peel-loop and/or remainder-loop.

Note: Option -qopt-assume-safe-padding is the replacement option for -opt-assume-safe-padding, which is deprecated in version 15.0.

Remainder Loop:

A Remainder Loop executes the remaining iterations when the trip( or loop)-count of the vector loop is not a multiple of the vector length. While this is unavoidable in many cases, having a large amount of time spent in remainder loops will lead to performance inefficiencies. For example, if the vector loop trip-count is 20 and the vector length is 16, the compiler generates a kernel loop that gets executed once (processing 16 elements in one vector, the vector length).  The remainder 4 iterations have to be executed in the remainder loop. Although the Intel compiler may vectorize the remainder-loop (as reported by -vec-report or -qopt-report ), it won't be as efficient as the kernel loop. For example, the remainder loop will use vector masks and it may have to use gathers/scatters instead of unit stride loads/stores (due to memory-fault-protection issues). The best way to address this is to refactor the algorithm/code in such a way that the remainder loop is NOT executed at runtime.  To do this, make trip counts a multiple of the vector length and/or making the trip count large compared to the vector length so that the overhead of any execution in the remainder-loop is comparatively low.

The compiler optimizations also take into account any knowledge of actual trip-count values. So if the trip-count is 20, compiler usually makes better decisions if it knows that the trip-count is 20 (trip-count is a constant known statically to the compiler) as opposed to a trip-count of n (symbolic value) that happens to have a value of 20 at runtime (maybe it is an input value read in from a file). In the latter case, you can help the compiler by using a "#pragma loop_count (20)" in C/C++ or "CDEC$ LOOP COUNT (20)" in Fortran pragma/directive before the loop.

Also take into account any unrolling of the vector-loop done by the compiler (by studying output from -vec-report6 option). For example, if the compiler vectorizes a loop (of trip-count n and vec-length 16) and unrolls the loop by 2 (after vectorization), each kernel-loop is designed to execute 32 iterations of the original src-loop. If the dynamic trip-count happens to be 20, the kernel-loop gets skipped completely and all execution will happen in the remainder-loop. If you encounter this issue, you can use the "#pragma nounroll" in C/C++ or "CDEC$ NOUNROLL" in Fortran to turn off the unrolling of the vector-loop. (You can also use the loop_count pragma described earlier instead to influence the compiler heuristics).

If you want to disable vectorization of the remainder-loop generated by the compiler, use "#pragma vector novecremainder" in C/C++ or "CDEC$ vector noremainder" in Fortran pragma/directive before the loop (Using this also disables vectorization of any peel-loop generated by the compiler for this loop). You can also use the compiler internal option -mP2OPT_hpo_vec_remainder=F to disable remainder loop vectorization (for all loops in the scope of the compilation). This is typically useful if you are analyzing the assembly-code of the vector-loop, and you want to identify clearly the vector-kernel loop from the line numbers (Otherwise you have to carefully sift through multiple versions of the loop in the assembly - kernel/remainder/peel to identify which one you are looking at).

Peel Loop:

Compiler generates dynamic-peel loops typically to align one of the memory accesses inside the loop. The peel-loop peels a few iterations of the original src-loop until the candidate memory-access gets aligned. The peel-loop is guaranteed to have a trip-count that is smaller than the vector-length. This optimization is done so that the kernel vector-loop can utilize more aligned load/store instructions - thus increasing the perf efficiency of the kernel-loop. But the peel-loop itself (even though it may be vectorized by the compiler) is less efficient (Study the -vec-report6 output from the compiler). The best way to address this is to refactor the algorithm/code in such a way that the accesses are aligned and the compiler knows about the alignment following the vectorizer alignment BKMs. If the compiler knows that all accesses are aligned (say if the user correctly uses "#pragma vector aligned" before the loop so that compiler can safely assume all memory accesses inside the loop are aligned), then there will be no peel-loop generated by the compiler.

You can also use the loop_count pragma described earlier to influence the compiler decision of whether or not to create a peel loop.

You can instruct the compiler to NOT generate a dynamic peel loop by adding  "#pragma vector unaligned" in C/C++ or "CDEC$ vector unaligned" in Fortran pragma/directive before the loop in the source. Another way to suppress dynamic peeling is to use the compiler internal option -mP2OPT_vec_alignment=6 (for all loops in the scope of the compilation).

You can use the vector pragma/directive with the novecremainder clause (as mentioned above) to disable vectorization of the peel loop generated by the compiler. You can also use the compiler internal option -mP2OPT_hpo_vec_peel=F to disable peel-loop vectorization (for all loops in the scope of the compilation) - in this case, compiler may still do dynamic peeling for alignment in some cases, but such peeled loops will NOT be vectorized.

It may be undesirable to have a dynamic-peel loop when the trip-count of the loop is expected to be small. Compiler uses any knowledge of actual trip-count of the loop (static constant, loop count pragma, etc.) before it decides to do dynamic peeling for alignment. But in many cases, this information may not be available to the compiler. One way to provide this information is to add a "#pragma loop_count (20)" in C/C++ or "CDEC$ LOOP COUNT (20)" in Fortran pragma/directive before the loop (with the appropriate value for the trip-count). Another way to provide this information (will apply to all vector-candidate loops in the scope of the compilation) is to use the internal option -mP2OPT_hpo_vec_esttrip=<n1>, where n1 is the estimated trip-count of the vector candidate-loop. Low values of n1 will bias the compiler towards skipping generation of dynamic-peel loops.

Example:

% cat -n t2.c

           1  #include <stdio.h>
           2
           3  void foo1(float *a, float *b, float *c, int n)
           4  {
           5    int i;
           6  #pragma ivdep
           7    for (i=0; i<n; i++) {
           8      a[i] *= b[i] + c[i];
           9    }
          10  }
          11
          12  void foo2(float *a, float *b, float *c, int n)
          13  {
          14    int i;
          15  #pragma ivdep
          16    for (i=0; i<20; i++) {
          17      a[i] *= b[i] - c[i];
          18    }
          19  }

For loop at line 7, compiler generates a kernel-vector-loop (unrolled after vectorization by a factor of 2) and a peel-loop and remainder loop, both of which are vectorized.

For loop at line 16, compiler takes advantage of the fact that the trip-count is a constant (20) and generates a kernel-loop that is vectorized (and not unrolled). The remainder loop (of 4 iterations) is completely unrolled by the compiler (and not vectorized). There is no peel-loop generated.

% icc -O2 -vec-report6 t2.c -c -mmic -inline-level=0
t2.c(8): (col. 5) remark: vectorization support: reference a has aligned access.
t2.c(8): (col. 5) remark: vectorization support: reference a has aligned access.
t2.c(8): (col. 5) remark: vectorization support: reference b has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: reference c has aligned access.
t2.c(8): (col. 5) remark: vectorization support: unaligned access used inside loop body.
t2.c(7): (col. 3) remark: vectorization support: unroll factor set to 2.
t2.c(7): (col. 3) remark: LOOP WAS VECTORIZED.
t2.c(8): (col. 5) remark: vectorization support: reference a has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: reference a has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: reference b has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: reference c has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: unaligned access used inside loop body.
t2.c(7): (col. 3) remark: PEEL LOOP WAS VECTORIZED.
t2.c(8): (col. 5) remark: vectorization support: reference a has aligned access.
t2.c(8): (col. 5) remark: vectorization support: reference a has aligned access.
t2.c(8): (col. 5) remark: vectorization support: reference b has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: reference c has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: reference a has aligned access.
t2.c(8): (col. 5) remark: vectorization support: reference a has aligned access.
t2.c(8): (col. 5) remark: vectorization support: reference b has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: reference c has unaligned access.
t2.c(8): (col. 5) remark: vectorization support: unaligned access used inside loop body.
t2.c(7): (col. 3) remark: REMAINDER LOOP WAS VECTORIZED.
t2.c(17): (col. 5) remark: vectorization support: reference a has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: reference a has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: reference b has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: reference c has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: unaligned access used inside loop body.
t2.c(16): (col. 3) remark: LOOP WAS VECTORIZED.
t2.c(17): (col. 5) remark: vectorization support: reference a has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: reference a has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: reference b has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: reference c has unaligned access.
t2.c(17): (col. 5) remark: vectorization support: unaligned access used inside loop body.
t2.c(16): (col. 3) remark: loop was not vectorized: vectorization possible but seems inefficient.

Increase the size of your arrays and use option -qopt-assume-safe-padding to improve performance:

This option determines whether the compiler assumes that variables and dynamically allocated memory are padded past the end of the object.

When -qopt-assume-safe-padding is specified, the compiler assumes that variables and dynamically allocated memory are padded. This means that code can access up to 64 bytes beyond what is specified in your program. The compiler does not add any padding for static and automatic objects when this option is used, but it assumes that code can access up to 64 bytes beyond the end of the object, wherever the object appears in the program. To satisfy this assumption, you must increase the size of static and automatic objects in your program when you use this option.

1. One example of where this option can help is in the sequences generated by the compiler for vector-remainder and vector-peel loops. This option may improve performance of memory operations in such loops.

If this option is used in the compilation above, compiler will assume that the arrays a, b, and c have a padding of atleast 64 bytes beyond n.

If these arrays were allocated using malloc such as:

ptr = (float *)malloc(sizeof(float) * n);

then they should be changed by the user to say:

ptr = (float *)malloc(sizeof(float) * n + 64);

After making such changes (to satisfy the legality requirements for using this option), if you add this option to the compilation above, you get the following (higher-performing) sequence for the peel-loop generated for loop at line 7:

..B2.7:                         # Preds ..B2.9 ..B2.6 Latency 13
        vpcmpgtd  %zmm0, %zmm2, %k0                             #7.3 c1
        nop                                                     #7.3 c5
        knot      %k0, %k1                                      #7.3 c9
        jkzd      ..B2.9, %k1   # Prob 20%                      #7.3 c13
                                # LOE rdx rbx rbp rsi rdi r9 r10 r11 r12 r13 r14
 r15 eax ecx r8d zmm0 zmm1 zmm2 zmm3 k1
..B2.8:                         # Preds ..B2.7 Latency 53
        vmovaps   %zmm1, %zmm4                                  #8.13 c1
        vmovaps   %zmm1, %zmm5                                  #8.20 c5
        vmovaps   %zmm1, %zmm6                                  #8.5 c9
        vloadunpacklps (%rsi,%r10,4), %zmm4{%k1}                #8.13 c13
        vloadunpacklps (%rdx,%r10,4), %zmm5{%k1}                #8.20 c17
        vloadunpacklps (%rdi,%r10,4), %zmm6{%k1}                #8.5 c21
        vloadunpackhps 64(%rsi,%r10,4), %zmm4{%k1}              #8.13 c25
        vloadunpackhps 64(%rdx,%r10,4), %zmm5{%k1}              #8.20 c29
        vloadunpackhps 64(%rdi,%r10,4), %zmm6{%k1}              #8.5 c33
        vaddps    %zmm5, %zmm4, %zmm7                           #8.20 c37
        vmulps    %zmm7, %zmm6, %zmm8                           #8.5 c41
        nop                                                     #8.5 c45
        vpackstorelps %zmm8, (%rdi,%r10,4){%k1}                 #8.5 c49
        vpackstorehps %zmm8, 64(%rdi,%r10,4){%k1}               #8.5 c53
        movb      %al, %al                                      #8.5 c53
                                # LOE rdx rbx rbp rsi rdi r9 r10 r11 r12 r13 r14
 r15 eax ecx r8d zmm0 zmm1 zmm2 zmm3
..B2.9:                         # Preds ..B2.7 ..B2.8 Latency 9
        addq      $16, %r10                                     #7.3 c1
        vpaddd    %zmm3, %zmm2, %zmm2                           #7.3 c5
        cmpq      %r11, %r10                                    #7.3 c5
        jb        ..B2.7        # Prob 82%                      #7.3 c9

Without this option, the compiler generates this lower performing sequence for the peel-loop at line 7 using gather/scatter:

..B2.7:                         # Preds ..B2.9 ..B2.6 Latency 13
        vpcmpgtd  %zmm0, %zmm2, %k0                             #7.3 c1
        nop                                                     #7.3 c5
        knot      %k0, %k4                                      #7.3 c9
        jkzd      ..B2.9, %k4   # Prob 20%                      #7.3 c13
                                # LOE rax rdx rbx rbp rsi rdi r9 r11 r13 r15 ecx
 r8d r10d zmm0 zmm1 zmm2 zmm3 k4
..B2.8:                         # Preds ..B2.7 Latency 57
        vmovaps   .L_2il0floatpacket.10(%rip), %zmm8            #8.5 c1
        vmovaps   %zmm1, %zmm4                                  #8.13 c5
        lea       (%rsi,%r13), %r14                             #8.13 c5
        vmovaps   %zmm1, %zmm5                                  #8.20 c9
        kmov      %k4, %k2                                      #8.13 c9
..L15:                                                          #8.13
        vgatherdps (%r14,%zmm8,4), %zmm4{%k2}                   #8.13
        jkzd      ..L14, %k2    # Prob 50%                      #8.13
        vgatherdps (%r14,%zmm8,4), %zmm4{%k2}                   #8.13
        jknzd     ..L15, %k2    # Prob 50%                      #8.13
..L14:                                                          #
        vmovaps   %zmm1, %zmm6                                  #8.5 c21
        kmov      %k4, %k3                                      #8.20 c21
        lea       (%rdx,%r13), %r14                             #8.20 c25
        lea       (%rdi,%r13), %r12                             #8.5 c25
..L17:                                                          #8.20
        vgatherdps (%r14,%zmm8,4), %zmm5{%k3}                   #8.20
        jkzd      ..L16, %k3    # Prob 50%                      #8.20
        vgatherdps (%r14,%zmm8,4), %zmm5{%k3}                   #8.20
        jknzd     ..L17, %k3    # Prob 50%                      #8.20
..L16:                                                          #
        vaddps    %zmm5, %zmm4, %zmm7                           #8.20 c37
        kmov      %k4, %k1                                      #8.5 c37
..L19:                                                          #8.5
        vgatherdps (%r12,%zmm8,4), %zmm6{%k1}                   #8.5
        jkzd      ..L18, %k1    # Prob 50%                      #8.5
        vgatherdps (%r12,%zmm8,4), %zmm6{%k1}                   #8.5
        jknzd     ..L19, %k1    # Prob 50%                      #8.5
..L18:                                                          #
        vmulps    %zmm7, %zmm6, %zmm9                           #8.5 c49
        nop                                                     #8.5 c53
..L21:                                                          #8.5
        vscatterdps %zmm9, (%r12,%zmm8,4){%k4}                  #8.5
        jkzd      ..L20, %k4    # Prob 50%                      #8.5
        vscatterdps %zmm9, (%r12,%zmm8,4){%k4}                  #8.5
        jknzd     ..L21, %k4    # Prob 50%                      #8.5
..L20:                                                          #
                                # LOE rax rdx rbx rbp rsi rdi r9 r11 r13 r15 ecx
 r8d r10d zmm0 zmm1 zmm2 zmm3
..B2.9:                         # Preds ..B2.7 ..B2.8 Latency 9
        addq      $16, %rax                                     #7.3 c1
        addq      $64, %r13                                     #7.3 c1
        vpaddd    %zmm3, %zmm2, %zmm2                           #7.3 c5
        cmpq      %r9, %rax                                     #7.3 c5
        jb        ..B2.7        # Prob 82%                      #7.3 c9

2. Another example where the option is useful is in the handling of short integer type conversions. In this case, the code generated by the compiler under default options can be improved with the addition of the option -qopt-assume-safe-padding.

void foo(short * restrict a, short *restrict b, short * restrict c)
{
   int i;

   for(i = 0; i < N; i++) {
       a[i] = b[i] + c[i];
   }
}

In the main kernel loop, compiler adds checks for each load/store (to protect against memory faults). In the remainder loop, gather/scatters will be emitted:

Main kernel loop under default options:

..B1.6:
        lea       (%rax,%rsi), %r10
        vloadunpackld (%rax,%rsi){sint16}, %zmm1
        andq      $63, %r10
        cmpq      $32, %r10
        jle       ..L3
        vloadunpackhd 64(%rax,%rsi){sint16}, %zmm1
..L3:
        vprefetch1 256(%rax,%rsi)
        lea       (%rax,%rdx), %r10
        vloadunpackld (%rax,%rdx){sint16}, %zmm2
        andq      $63, %r10
        cmpq      $32, %r10
        jle       ..L4
        vloadunpackhd 64(%rax,%rdx){sint16}, %zmm2
..L4:
        vprefetch0 128(%rax,%rsi)
        vpaddd    %zmm2, %zmm1, %zmm3
        vprefetch1 256(%rax,%rdx)
        vpandd    %zmm0, %zmm3, %zmm4
        vprefetch0 128(%rax,%rdx)
        addq      $16, %rcx
        vprefetch1 256(%rax,%rdi)
        lea       (%rax,%rdi), %r10
        andq      $63, %r10
        cmpq      $32, %r10
        jle       ..L5
        vpackstorehd %zmm4{uint16}, 64(%rax,%rdi)
..L5:
        vpackstoreld %zmm4{uint16}, (%rax,%rdi)
        vprefetch0 128(%rax,%rdi)
        addq      $32, %rax
        cmpq      $992, %rcx
        jb        ..B1.6

Remainder loop generated by compiler under default options:

..L9:
        vpgatherdd 1984(%rdx,%zmm3,2){sint16}, %zmm1{%k2}
        jkzd      ..L8, %k2
        vpgatherdd 1984(%rdx,%zmm3,2){sint16}, %zmm1{%k2}
        jknzd     ..L9, %k2
..L8:
        vpaddd    %zmm1, %zmm0, %zmm2
        vpandd    .L_2il0floatpacket.3(%rip), %zmm2, %zmm4
        nop
..L11:
        vpscatterdd %zmm4{uint16}, 1984(%rdi,%zmm3,2){%k3}
        jkzd      ..L10, %k3    
        vpscatterdd %zmm4{uint16}, 1984(%rdi,%zmm3,2){%k3}
        jknzd     ..L11, %k3    
..L10:

When the option -qopt-assume-safe-padding is added, compiler generates the following higher performing versions for the main kernel loop and remainder loop:

Main kernel loop with -qopt-assume-safe-padding option:

..B1.6:
        vloadunpackld (%rax,%rsi){sint16}, %zmm1
        vprefetch1 256(%rax,%rsi)
        vloadunpackld (%rax,%rdx){sint16}, %zmm2
        vprefetch0 128(%rax,%rsi)
        vloadunpackhd 64(%rax,%rsi){sint16}, %zmm1
        vprefetch1 256(%rax,%rdx)
        vloadunpackhd 64(%rax,%rdx){sint16}, %zmm2
        vprefetch0 128(%rax,%rdx)
        vpaddd    %zmm2, %zmm1, %zmm3
        vprefetch1 256(%rax,%rdi)
        vpandd    %zmm0, %zmm3, %zmm4
        vprefetch0 128(%rax,%rdi)
        addq      $16, %rcx
        movb      %dl, %dl
        vpackstoreld %zmm4{uint16}, (%rax,%rdi)
        vpackstorehd %zmm4{uint16}, 64(%rax,%rdi)
        addq      $32, %rax
        cmpq      $992, %rcx
        jb        ..B1.6

Remainder loop with -qopt-assume-safe-padding option added (higher performing version with no gather/scatter):

        vloadunpackld 1984(%rsi){sint16}, %zmm0{%k1}
        vloadunpackld 1984(%rdx){sint16}, %zmm1{%k1}
        vloadunpackhd 2048(%rsi){sint16}, %zmm0{%k1}
        vloadunpackhd 2048(%rdx){sint16}, %zmm1{%k1}
        vpaddd    %zmm1, %zmm0, %zmm2
        vpandd    .L_2il0floatpacket.3(%rip), %zmm2, %zmm3
        nop
        vpackstoreld %zmm3{uint16}, 1984(%rdi){%k1}
        vpackstorehd %zmm3{uint16}, 2048(%rdi){%k1}
        movb      %al, %al

NEXT STEPS

It is essential that you read this guide from start to finish using the built-in hyperlinks to guide you along a path to a successful port and tuning of your application(s) on Intel® Xeon Phi™ architecture. The paths provided in this guide reflect the steps necessary to get best possible application performance.

Back the main chapter Vectorization Essentials.

Para obter informações mais completas sobre otimizações do compilador, consulte nosso aviso de otimização.