[llvm-dev] [LLVM] (RFC) Addition/Support of new Vectorization Pragmas in LLVM

Terry Greyzck via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 15 13:05:20 PDT 2019


The ivdep pragma is designed to do exactly what the name states - ignore
vector dependencies.  Cray Research first implemented this in 1978 in
their CFT compiler, and has supported it since.

This pragma is typically used by application developers who want
vectorized code when the compiler cannot automatically determine safety;
it is not equivalent to the OpenMP SIMD pragma in that the compiler is
still expected to automatically detect such things as reductions.

The Cray implementation accepts an optional 'safevl=<const>' clause,
however this is not commonly used and not really needed for new
implementations.

Characteristics of ivdep:

   * ivdep can be applied to any loop in a nest, but only affects the
     immediately following loop
       *  Only trims dependencies at that loop nest level
       *  If the user annotates more than one loop in a loop nest, only
           the ivdep on the innermost loop or loops is honored

   * ivdep can be used on for (), while {}, and do { } while loops

   * Primarily ivdep allows ambiguous dependencies to be ignored, examples:
       *  p[i] = q[j]
       *  a[ix[i]] = b[iy[i]]
       *  a[ix[i]] += 1.0

   * ivdep still requires automatic detection of reductions, including
     multiple homogeneous reductions on a single variable, examples:
       *  x = x + a[i]
       *  x = x + a[i]; if ( c[i] > 0.0 ) { x = x + b[i] }

   * ivdep implies loop control variables, loop termination expressions,
     and primary induction increment expressions do not alias anything
     else in the loop nest body

   * For Fortran, ivdep allows the following for array syntax
       *  Assumption that there is no overlap between the target and right
           hand side in assignments
       *  Assumption there is no overlap between the target and the
           address expression for the target

Things that ivdep will /not /do:

   * ivdep on a loop nest will not diagnose or reject loops with
     'provable' dependencies

   * ivdep on a loop nest will not restructure loops as necessary for
     correctness
       * will not reorder statements for dependence resolution
       * will not peel for dependence resolution
       * will not perform loop distribution to remove recurrences

   * ivdep does not force vector code to be generated; the compiler can
     decide to not vectorize the loop nest for any reason it sees fit,
     including but not limited to:
       * Expectations the scalar version will be faster than the vector
       * Non-vectorizable function calls in the loop nest
       * Vector operations that lack hardware support
       * Extremely unstructured control flow

-- 
Terry Greyzck  |  Cray Inc.
Sr. Principal Engineer, Compiler Optimization


More information about the llvm-dev mailing list