Hi Jakub, > -----Original Message----- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Wednesday, January 29, 2014 6:31 AM > 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 Tue, Jan 28, 2014 at 04:55:38PM +0000, Iyer, Balaji V wrote: > > 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. > > I guess for the C++ iterators, if in the _Cilk_for model you need to provide > number of iterations before parallelization, it really depends on what the > standard allows and what you want to do exactly.
Yes, I need the value before the parallelization context hits. This is why in my last patch I had the parallel around the body and omp for around the _Cilk-for statement. > If you need to provide the iteration count before spawning the threads and > the standard allows you that, then just lower it in the C++ FE already so that > you do: > vector<int>::iterator temp = array.begin (); > sizetype tempcount = (array.end () - temp); before the parallel, and then > #pragma omp parallel firstprivate(temp, tempcount) > _Cilk_for (sizetype temp2 = 0; temp2 < tempcount; temp2++) > { > vector<int>::iterator ii = temp + temp2; > <body> > } This is kind of what I did (atlest tried to accomplish what you mentioned above). I can look into doing this, but is it possible for you to accept the patch as-is and we will look into fixing it in the future? Thanks, Balaji V. Iyer. > or similar. The C++ FE needs to lower the C++ iterators anyway, the middle- > end can really only work with integral or pointer iterators, and it depends on > how exactly the Cilk+ standard defines _Cilk_for with iterators (what > methods must be implemented on the iterators and what methods and in > what order should be called). > > Jakub