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

Michael Kruse via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 26 13:19:22 PDT 2019

Am Mo., 26. Aug. 2019 um 14:16 Uhr schrieb Terry Greyzck <tdg at cray.com>:
> That said, trying to predict in the front end what edges will eventually
> cause difficulties with automatic vectorization does seem problematic.
> Generally "ivdep" is an assist to automatic vectorization; for older
> Cray compilers that basically means the front end does nothing but pass
> along the "ivdep" property, and dependency analysis for vectorization
> uses that property directly.

This is what makes implementing ivep with Cray's semantics difficult.
To be compatible, we'd need to replicate Cray's cycle breaking.
Missing a detected reduction means ignoring its dependency cycle and
therefore a miscompilation where Cray's vectorizer might have produced
correct code (and the other way around). Unpredictably miscompiling
programs is probably not what users would expect.

> One thing to remember is that is perfectly valid for the "ivdep" loop
> nest to still be rejected as a vector candidate for any reason, so
> support for an "ivdep" pragma could be implemented in stages if desired.

The vectorizer rejecting any "ivdep" loop that has unbroken dependency
cycles makes the annotation useless. We'd need to have a description
of dependencies that any Cray compiler (including past and future
versions) will ignore (instead of breaking by e.g. reduction
detection) with ivdep such that Clang never miscompiles a loop that a
Cray compiler compiles correctly.


More information about the llvm-dev mailing list