This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 04/19/13 08:29, Jakub Jelinek wrote:
Hi!

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 am also ignoring the "vectorlength" clause as you have done with safelen, waiting for Richi's loop preservation patch.

It seems that the Cilk Plus folk have not finalized the assert clause, and it's currently missing from the current spec. I have left the assert clause in, as it seems they'll include something similar with a different syntax.

Otherwise, I'm using the same OMP_SIMD codes, as well as reusing your OMP_CLAUSE_LINEAR*. For the firstprivate, lastprivate, private, and reduction clauses, I'm reusing even the parsing bits for OMP since the Cilk Plus spec uses the same exact syntax. Perhaps eventually we could use some bits on the OMP_SIMD tree to differentiate an OMP_SIMD from a Cilk SIMD variant, and then use those to typecheck that the vectorlength and assert clauses are only used for Cilk Plus' #pragma simd.

I am missing a few minor things (some typechecking restrictions for longjmp() inside for-loop bodies, etc), but the parsing is basically done. See the plethora of tests :).

How does this look, or do would you prefer another approach?

Attachment: curr
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]