On 2/15/2014 3:36 PM, Renato Golin wrote:
On 15 February 2014 19:26, Jakub Jelinek <ja...@redhat.com> 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
