RE: [gomp4] Some progress on #pragma omp simd

["Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>]

> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
> owner@gcc.gnu.org] On Behalf Of Aldy Hernandez
> Sent: Wednesday, May 01, 2013 11:52 AM
> To: Jakub Jelinek
> Cc: Iyer, Balaji V; Richard Henderson; gcc-patches@gcc.gnu.org
> Subject: Re: [gomp4] Some progress on #pragma omp simd
> 
> On 04/24/13 01:01, Jakub Jelinek wrote:
> > On Tue, Apr 23, 2013 at 09:32:29PM +0000, Iyer, Balaji V wrote:
> >> 	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.
> >
> > The documentation doesn't suggest that.  Anyway, so #pragma simd
> > should be equivalent to #pragma omp simd wrt. inter-iteration
> > dependencies, and #pragma simd vectorlength(a, b, c) to #pragma omp
> > simd safelen(max (a, b, c)) ?  If so, then the FE could emit OMP_SIMD
> > for #pragma simd, and if vectorlength is present, add
> > OMP_CLAUSE_SAFELEN with the maximum of the values in all vectorlength
> > clauses, and keep the vectorlength clauses around too as
> > CILK_CLAUSE_VECTORLENGTH as hints to the vectorizer?
> 
> Well, it looks like things are bit simpler than expected.
> 
> Multiple vectorlength clauses are being deprecated or eliminated in the
> upcoming spec.  So it looks like vectorlength is the same thing as the safelen
> clause.
> 
> If you agree then I can get rid of OMP_CLAUSE_CILK_VECTORLENGTH and just
> emit an OMP_CLAUSE_SAFELEN.
> 
> Agreed?

To my best knowledge, Yes. I believe safelen requires/allows only 1 value, so we should do what Jakub mentioned (vectorlength (a, b, c)) should be converted to safelen (max(a,b,c))

> 
> >
> > Also, Aldy said that #pragma simd loops allow != condition, how do you
> > compute number of iterations in that case if the increment isn't constant?
> > As conditional depending on whether increment is positive or negative?
> > != condition isn't allowed in OpenMP, so there it is always obvious
> > which direction it should iterate, and the expansion code will assume
> > if it sees NE_EXPR that it is just folded border test (comparison with
> > maximum or minimum value).
> 
> I verified with the Cilk Plus folks, and the number of iterations is calculated with
> a conditional.  So to evaluate something like this:
> 
> // incr = -1
> for (i=N; i != limit; i += incr)
>    [body]
> 
> We would generate something like this:
> 
> if (incr > 0) count =  (limit - N) / incr; else count = (N - limit) / -incr; for (i=N; count
> > 0; --count)
>    [body]

Sounds OK.