Vectorizer Pragmas

Tim Prince
Sat Feb 15 22:49:00 GMT 2014

On 2/15/2014 3:36 PM, Renato Golin wrote:
> On 15 February 2014 19:26, Jakub Jelinek <> wrote:
>> GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one
>> can be used without rest of OpenMP by using -fopenmp-simd switch.
> Does the simd/omp have control over the tree vectorizer? Or are they
> just flags for the omp implementation?
>> I don't see why we would need more ways to do the same thing.
> Me neither! That's what I'm trying to avoid.
> Do you guys use those pragmas for everything related to the
> vectorizer? I found that the Intel pragmas (not just simd and omp) are
> pretty good fit to most of our needed functionality.
> Does GCC use Intel pragmas to control the vectorizer? Would be good to
> know how you guys did it, so that we can follow the same pattern.
> Can GCC vectorize lexical blocks as well? Or just loops?
> IF those pragmas can't be used in lexical blocks, would it be desired
> to extend that in GCC? The Intel guys are pretty happy implementing
> simd, omp, etc. in LLVM, and I think if the lexical block problem is
> common, they may even be open to extending the semantics?
> cheers,
> --renato
gcc ignores the Intel pragmas, other than the OpenMP 4.0 ones.  I think 
Jakub may have his hands full trying to implement the OpenMP 4 pragmas, 
plus GCC ivdep, and gfortran equivalents.  It's tough enough 
distinguishing between Intel's partial implementation of OpenMP 4 and 
the way it ought to be done.
In my experience, the (somewhat complicated) gcc --param options work 
sufficiently well for specification of unrolling.  In the same vein, I 
haven't seen any cases where gcc 4.9 is excessively aggressive in 
vectorization, so that a #pragma novector plus scalar unroll  is needed, 
as it is with Intel compilers.
I'm assuming that Intel involvement with llvm is aimed toward making it 
look like Intel's own compilers; before I retired, I heard a comment 
which indicated a realization that the idea of pushing llvm over gnu had 
been over-emphasized.  My experience with this is limited; my Intel 
Android phone broke before I got too involved with their llvm Android 
compiler, which had some bad effects on both gcc and Intel software 
usage for normal Windows purposes.
I've never seen a compiler where pragmas could be used to turn on 
auto-vectorization when compile options were set to disable it. The 
closest to that is the Intel(r) Cilk(tm) Plus where CEAN notation 
implies turning on many aggressive optimizations, such that full 
performance can be achieved without problematical -O3.  If your idea is 
to obtain selective effective auto-vectorization in source code which is 
sufficiently broken that -O2 -ftree-vectorize can't be considered or 
-fno-strict-aliasing has to be set, I'm not about to second such a motion.

Tim Prince

More information about the Gcc mailing list