[omp4/cilkplus] jumps in/out-of #pragma simd for

[Aldy Hernandez <aldyh at redhat dot com>]

[list copied]

On 06/20/13 11:20, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 05:08:38PM -0500, Aldy Hernandez wrote:
> > On 06/19/13 16:43, Jakub Jelinek wrote:
> > > On Wed, Jun 19, 2013 at 04:39:52PM -0500, Aldy Hernandez wrote:
> > > > Jumps are disallowed into or out of the body of the for loop
> > > > associated with a #pragma simd.

> I guess my preference would be CILK_SIMD tree (handled the same
> as OMP_SIMD during genericization/instantiation), and let
> gimplification turn that into (note CILKSIMD added, and everything
> reordered):
> GF_OMP_FOR_KIND_FOR		0 << 0	#pragma omp for
> GF_OMP_FOR_KIND_DISTRIBUTE	1 << 0	#pragma omp distribute
> GF_OMP_FOR_KIND_SIMD		2 << 0	#pragma omp simd
> GF_OMP_FOR_KIND_CILKSIMD	3 << 0	#pragma simd
>
> This way, when testing for whether it is any kind of simd
> we can use gimple_omp_for_kind (stmt) & GF_OMP_FOR_KIND_SIMD
> instead of the current gimple_omp_for_kind (stmt) == GF_OMP_FOR_KIND_SIMD
> test, and the equality can be tested where we expect differences
> (say, in the diagnostics - provide different wording), or in nesting
> restrictions/combined constructs etc.

I have done as suggested, and cleaned things up along the way.

I believe this is the last remaining TODO on my Cilk Plus pragma simd 
list.  Everything else is dependent on OMP4.

Is this what you had in mind?

If you'd like, I can submit the OMP changes separately so we can put 
them on the OMP4 branch.  However, my plan is to start pushing the OMP4 
supporting bits (from gomp-4_0-branch) and the Cilk Plus #pragma simd 
support (from aldyh/cilk-in-gomp) next week, so perhaps everything will 
fall into place shortly.  As you wish...

Aldy

Attachment: curr
Description: Text document