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: [PING] [PATCH] _Cilk_for for C and C++



> -----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';
> 'rth@redhat.com'
> Subject: RE: [PING] [PATCH] _Cilk_for for C and C++
> 
> > -----Original Message-----
> > From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
> > owner@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'; 'rth@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.


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