> -----Original Message-----
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, November 27, 2013 2:43 PM
> To: Jason Merrill; Iyer, Balaji V; Aldy Hernandez
> Cc: gcc-patches@gcc.gnu.org; r...@redhat.com; Jakub Jelinek
> Subject: Re: [PATCH] _Cilk_for for C and C++
>
> On 11/27/13 10:06, Jason Merrill wrote:
> > On 11/25/2013 11:03 PM, Iyer, Balaji V wrote:
> >
> > On a broad note, I think there's a lot of OpenMP code you could be
> > reusing here rather than writing it all again. And that way Cilk code
> > will benefit from improvements to OpenMP handling, and vice versa. It
> > probably makes sense to turn Cilk_for into an OMP_FOR loop, and then
> > gimplify into GIMPLE_OMP_FOR, rather than create a new tree code and
> > handle everything at the tree level. But I don't know the OMP code
> > well enough to suggest exactly how that would work.
> That's certainly the direction I'd like to see this work go as well. To the
> fullest
> extent possible Cilk+ should be layering on top of the OpenMP 4 work -- ie,
> Cilk+ should really be dealing with parsing issues, then handoff to OpenMP
> for the real work.
Hello Jeff and Jason,
I completely agree with you that there are certain parts of Cilk Plus
that is similar to OMP4, namely #pragma simd and SIMD-enabled functions
(formerly called elemental functions). But, the Cilk keywords is almost
completely orthogonal to OpenMP. They are semantically different and one
cannot be transformed to another. Cilk uses automatically load-balanced
work-stealing using the Cilk runtime, whereas OMP uses work sharing via OMP
runtime. There are a number of other semantic differences but this is the
core-issue. #pragma simd and #pragma omp have converged in several places but
the Cilk part has always been different from OpenMP.
I have thought about sharing routines with OpenMP and have done it in
several parts of Cilk plus. It is not possible to share any middle end work
between Cilk keywords and OpenMP because they are fundamentally different. I
have shared some parsing parts with omp in C.
Since we are talking about _Cilk_for loops, maybe an example of how a
compiler is supposed break down a _Cilk_for loop will help. Please see the
example below. It is a simple main routine with one _Cilk_for in it and it
returns a local variable X that may or may not be read/written in the body:
int main (void)
{
int X = 0;
_Cilk_for (int ii = 5; ii < 15; ii++)
{
<body>
}
return X;
}
This program is converted to the following:
/* Low and high fields are passed in by the runtime using the user defined
grainsize or the rumtime
computed one. Data field is ignored in GCC, please see below. */
cilk_for_helper_function (void *data, int low, int high) {
for (ii = low; ii < high; ii++)
<body>;
}
int main (void)
{
int X = 0;
/* This function is actually a call the the runtime whose
implementation is in
libcilkrts/runtime/cilk-abi-cilk-for.c. */
__cilkrts_cilk_for_64 (__cilk_for_001, /* Nested/Lambda function */
__cilk_for_001, /* Data used by the lambda
function, the runtime
does not worry about it. It is an interface to
pass the information to the lambda function. In
GCC we create a nested function so it is
ignored. */
10 /* loop_count
(15-5) */,
0 /* grain
value from the
#pragma grainsize pragma */ );
/* Note: if the trip-count is 32 bit then __cilkrts_cilk_for_64 is
replaced by __cilkrts_cilk_for_32 */
return X;
}
As you can tell, this is not how openmp handles a #pragma omp for loop.
Thanks,
Balaji V. Iyer.
>
> Jeff
