> -----Original Message----- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@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.
