> -----Original Message-----
> From: Jakub Jelinek [mailto:[email protected]]
> Sent: Tuesday, April 23, 2013 9:55 AM
> To: Aldy Hernandez
> Cc: Richard Henderson; [email protected]; Iyer, Balaji V
> Subject: Re: [gomp4] Some progress on #pragma omp simd
>
> On Mon, Apr 22, 2013 at 05:05:03PM -0500, Aldy Hernandez wrote:
> > On 04/19/13 08:29, Jakub Jelinek wrote:
> > >I've committed the following patch to gomp4 branch.
> > >#pragma omp simd loops now are handled with all its clauses from
> > >parsing up to and including omp expansion, so should actually run
> > >correctly, though haven't added any runtime testcases yet.
> >
> > I like it. Thanks for working on this.
> >
> > I've been working on rewriting the <#pragma simd> support on the
> > cilkplus branch to use a similar approach to what you do for openmp,
> > especially since both constructs seem to behave similarly, with the
> > exception of the "vectorlength" clause in Cilk Plus. Attached is a
> > patch against yours, doing so.
> >
> > The idea is that <#prama omp simd> and <#pragma simd> are pretty much
> > the same thing, so we can probably get away with outputting the same
> > OMP_SIMD tree code and letting omp do it's thing.
>
> I don't think you can use OMP_SIMD resp. GF_OMP_FOR_KIND_SIMD for
> #pragma simd, given that it has different semantics wrt. aliasing.
>
> Like:
> void
> foo (int *p, int *q)
> {
> int i;
> #pragma omp simd
> for (i = 0; i < 1024; i++)
> p[i] = q[i] + 1;
> }
> vs.
> void
> bar (int *p, int *q)
> {
> int i;
> #pragma simd
> for (i = 0; i < 1024; i++)
> p[i] = q[i] + 1;
> }
>
> It is a user error if one calls foo say with int arr[1028]; ... foo (arr + 4,
> arr);
> because through #pragma omp simd without safelen the programmer has
> asserted that all iterations can be executed in the same simd chunk (think
> about
> 4096 bytes long vectors in this case). So, #pragma omp simd expansion should
> be able to tell the vectorizer that it can ignore all inter-iteration
> dependencies
> during analysis.
>
> If I understood right, vectorlength isn't anything close to it, it is just a
> hint, if you
> vectorize, prefer this vector length, but the compiler is still responsible
> for doing
> the analysis, and punting if it can't prove there is no aliasing (or go for
> runtime
> checks).
Hi Jakub,
My apologies if the documentation did not explain this correctly. It
was written by compiler developers and not language developers. #pragma simd is
the guarantee the user gives the compiler that the inter-iteration dependencies
do not matter. So, if the user omits the vectorlength the clause then the
compiler can, in effect, choose N, where N is the number of loop iterations.
Thanks,
Balaji V. Iyer.
>
> There is #pragma ivdep in ICC, but it's definition is vague - the compiler is
> still
> supposed to do analysis, but if some dependency isn't certain, it can assume
> it
> doesn't happen (which is the fuzzy thing about it, if the compiler can prove
> there
> is some dependency, then the code is valid and vectorization can't be done).
>
> So, IMHO you want CILK_SIMD tree (but it can use OMP and CILK clauses etc.),
> and GF_OMP_FOR_KIND_CILK_SIMD or so, and perhaps it can be expanded etc.
> exactly the same as #pragma omp simd, except for not telling the loop
> optimizers that it should imply safelen(+infinity). Or another option is let
> the
> C/C++ FEs, when seeing #pragma omp simd without safelen clause just add one
> with some very large value (unsigned TYPE_MAX_VALUE of a type with precision
> > precision of the loop iterator?).
>
> BTW, what restrictions has Cilk+ on the for stmt after the pragma?
> OpenMP has lots of restrictions, it doesn't allow arbitrary for stmt there.
>
> Like is
> int i, j, k;
> #pragma simd
> for (i = 0, j = 4, k = 5; i < 10 && j < 12; i++, j += 2, k += 3)
> ...
> valid Cilk+? It isn't valid with #pragma omp simd...
>
> Jakub
