RFC: SIMD pragma independent of Cilk Plus / OpenMPv4

Tim Prince n8tm@aol.com
Mon Sep 9 14:18:00 GMT 2013


On 9/9/2013 9:37 AM, Tobias Burnus wrote:
> Dear all,
>
> sometimes it can be useful to annotate loops for better vectorization,
> which is rather independent from parallelization.
>
> For vectorization, GCC has [0]:
> a) Cilk Plus's  #pragma simd  [1]
> b) OpenMP 4.0's #pragma omp simd [2]
>
> Those require -fcilkplus and -fopenmp, respectively, and activate much
> more. The question is whether it makes sense to provide a means to ask
> the compiler for SIMD vectorization without enabling all the other things
> of Cilk Plus/OpenMP. What's your opinion?
>
> [If one provides it, the question is whether it is always on or not,
> which syntax/semantics it uses [e.g. just the one of Cilk or OpenMP]
> and what to do with conflicting pragmas which can occur in this case.]
>
>
> Side remark: For vectorization, the widely supported #pragma ivdep,
> vector, novector can be also useful, even if they are less formally
> defined. "ivdep" seems to be one of the more useful ones, whose
> semantics one can map to a safelen of infinity in OpenMP's semenatics
> [i.e. loop->safelen = INT_MAX].
>
> Tobias
>
> [0] In the trunk is currently only some initial middle-end support.
> OpenMP's imp simd is in the gomp-4_0-branch; Cilk Plus's simd has been
> submitted for the trunk at
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01626.html
> [1] http://www.cilkplus.org/download#open-specification
> [2] http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf
ifort/icc have a separate option -openmp-simd for the purpose of 
activating omp simd directives without invoking OpenMP.  In the previous 
release, in order to activate both OpenMP parallel and omp simd, both 
options were required (-openmp -openmp-simd).  In the new "SP1" release 
last week, -openmp implies -openmp-simd.  Last time I checked, turning 
off the options did not cause the compiler to accept but ignore all omp 
simd directives, as I personally thought would be desirable.  A few 
cases are active regardless of compile line option, but many will be 
rejected without matching options.

Current Intel implementations of safelen will fail to vectorize and give 
notice if the value is set unnecessarily large.  It's been agreed that 
increasing the safelen value beyond the optimum level should not turn 
off vectorization.  safelen(32) is optimum for several float/single 
precision cases in the Intel(r) Xeon Phi(tm) cross compiler; needless to 
say, safelen(8) is sufficient for 128-bit SSE2.

I pulled down an update of gcc gomp-4_0-branch yesterday and see in the 
not-yet-working additions to gcc testsuite there appears to be a move 
toward adding more cilkplus clauses to omp simd, such as firstprivate 
lastprivate (which are accepted but apparently ignored in the Intel omp 
simd implementation).
I'll be discussing in a meeting later today my effort to publish 
material including discussion of OpenMP 4.0 implementations.

-- 
Tim Prince



More information about the Gcc mailing list