> -----Original Message-----
> From: Iyer, Balaji V
> Sent: Monday, January 27, 2014 4:36 PM
> To: Jakub Jelinek
> Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: RE: [PING] [PATCH] _Cilk_for for C and C++
>
> > -----Original Message-----
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> > Sent: Monday, January 27, 2014 3:50 PM
> > To: Iyer, Balaji V
> > Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez';
> > 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'
> > Subject: Re: [PING] [PATCH] _Cilk_for for C and C++
> >
> > On Mon, Jan 27, 2014 at 08:41:14PM +0000, Iyer, Balaji V wrote:
> > > Did you get a chance to look at this _Cilk_for patch?
> >
> > IMHO it is not as much work as you are fearing, at most a few hours of
> > work to get it right, and well worth doing. So, please at least try
> > it out and if you get stuck with it, explain why.
>
> Hi Jakub,
> I tried it that way in the original patch submission for C
> (http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01369.html), but it hit a
> dead-end when I was trying to get STL iterators working for C++. This is why I
> re-structured things this way to get them both working.
>
> Thanks,
>
> Balaji V. Iyer.
>
Hi Jakub,
I thought about it a bit more, and the main issue here is that we need
access to the _Cilk_for loop's components both inside the child function and
the parent function.
So, at the moment, I have modelled the _Cilk_for as something like this:
#pragma omp for schedule (runtime: grain)
_Cilk-for (vector<int>::iterator ii = array.begin (); ii != array.end (); ii++)
#pragma omp parallel
{
<body>
}
>From what I understand, you feel this is a bit ugly and you want this to be
>modelled something like this?
#pragma omp parallel for schedule (runtime: grain)
_Cilk_for (vector<int>::iterator ii = array.begin (); ii != array.end(); ii++)
{
<body>
}
Am I right?
As it stands, doing it the way you suggested did not work when we have
iterators since iterator expansion pushed inside the child function and its
expanded variables are not accessible outside the child function by
gimplify_omp_for. That is, the expansion is put after #pragma omp parallel for
and that is all pulled into the child function and thus the information to
compute the count is lost for the parent function.
There is a hack that I think may get around this. This is a bit ugly and really
is not the way I would think of _Cilk_fors. I am OK with trying this if you
will accept it.
If I do something like this:
#pragma omp parallel for schedule (runtime:grain) if ((array.end() -
array.begin ())/1)
_Cilk_for (vector <int>::iterator ii = array.begin (); ii != array.end (); ii++)
{
<body>
}
The new addition is if clause where "if ((<end> - <start>) / <step>)"
Then, in the expand_parallel_task, I can extract the if (...) clause and then
pass the expression as a parameter for the loop-count. Yes, it's bit ugly but
if you are willing to accept it, I can try to implement this.
Please let me know.
Thanks,
Balaji V. Iyer.
