nu.og
> Subject: RE: [PING] [PATCH] _Cilk_for for C and C++
>
>
>
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Thursday, March 6, 2014 6:55 AM
> > To: Iyer, Balaji V
> > Cc: gcc-patc...@gcc.gnu.og
> > S
ez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: RE: [PING] [PATCH] _Cilk_for for C and C++
>
> Hi Jakub,
> Please see my responses below.
>
> > -Original Message-
> > From: Iyer, Balaji V
> > Sent: Thursday, F
On Wed, Feb 19, 2014 at 04:43:06AM +, Iyer, Balaji V wrote:
> Attached, please find a patch with the test case attached (for1.cc). The
> patch is the same but the cp-changelog has been modified to reflect the
> new test-case. Is this OK to install?
1) have you tested the patch at all? I see
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, February 12, 2014 12:10 PM
> To: Iyer, Balaji V
> Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@
On Wed, Feb 12, 2014 at 05:04:38PM +, Iyer, Balaji V wrote:
> I looked at the test code you send me (cf3.cc) at -O1 and it is removing
> all the lines you have shown above. Yes, I would imagine -O0 to have code
> that can be redundant or unnecessary. Some of it could be the artifact of
> inte
> > > More importantly, what is retval.1? I'd expect you should be using
> > > retval.0 there and have it also as firstprivate(retval.0) on the parallel.
> > > In *.omplower dump I actually see:
> > > retval.0 = operator- (D.2885, &i); ...
> > > retval.1 = opera
On Wed, Feb 12, 2014 at 03:14:23PM +, Iyer, Balaji V wrote:
> > The testcase is GPL as the original libgomp.c++/for-1.C testcase, so sure.
> > Perhaps it would be much better though if instead of having a compile time
> > testcase you'd just do what libgomp.c++/for-1.C does, just replace all th
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, February 12, 2014 9:59 AM
> To: Iyer, Balaji V
> Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@
On Mon, Feb 10, 2014 at 10:07:18PM +, Iyer, Balaji V wrote:
> I looked at both but forgot to test them with my implementation. Sorry
> about this. I have fixed the ICE issue. To make sure this does not
> happen further, I have added your test cf3.C into test suite (renamed to
> cf3.cc). I ho
nandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: RE: [PING] [PATCH] _Cilk_for for C and C++
>
> Hi Jakub,
>
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Monday, February 10, 2014 12:58
On Fri, Feb 07, 2014 at 10:14:21PM +, Iyer, Balaji V wrote:
> Attached, please find a fixed patch. Along with it, I have also
> added 2 changelog files for C and C++ respectively.
Have you even looked at the second testcase I've posted?
gimplification ICEs on it with your latest patch, b
On Fri, Feb 07, 2014 at 02:33:41PM +, Iyer, Balaji V wrote:
> > So, the issues I see:
> > 1) what is iter.1, why do you have it at all, and, after all, the iterator
> > is a class
> > that needs to be constructed/destructed in the general way, so creating any
> > further copies of something is
;; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: Re: [PING] [PATCH] _Cilk_for for C and C++
>
> On Wed, Feb 05, 2014 at 05:27:26AM +, Iyer, Balaji V wrote:
> > Attached, please find a fixed patch (diff.txt) that will do as you
> re
On Wed, Feb 05, 2014 at 05:27:26AM +, Iyer, Balaji V wrote:
> Attached, please find a fixed patch (diff.txt) that will do as you
> requested (model _Cilk_for like a #pragma omp parallel for). Along with this,
> I have also attached two Changelog entries (1 for C and 1 for C++).
>
es@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: RE: [PING] [PATCH] _Cilk_for for C and C++
>
> Hi Jakub,
>
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Wednesday, January 29, 2014 6:31 AM
> > To:
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';
> '
On Tue, Jan 28, 2014 at 04:55:38PM +, 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 mo
> -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]
cc-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 +, Iyer, Balaji V wrote:
> > Did you get a chance to look at this _Cilk_for patch?
>
> IMHO it is not as much work
On Mon, Jan 27, 2014 at 08:41:14PM +, 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 wit
> To: Jakub Jelinek
> Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: RE: [PATCH] _Cilk_for for C and C++
>
>
>
> > -Original Message-
> > From: Jakub Jeli
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Friday, January 24, 2014 2:42 PM
> To: Iyer, Balaji V
> Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
On Thu, Jan 23, 2014 at 04:38:53PM +, Iyer, Balaji V wrote:
> This is how I started to think of it at first, but then when I thought
> about it ... in _Cilk_for unlike the #pragma simd's for, the for statement -
> not the body - (e.g. "_Cilk_for (int ii = 0; ii < 10; ii++") doesn't real
Hi Jakub,
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, January 23, 2014 5:13 AM
> To: Iyer, Balaji V
> Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@red
On Sun, Jan 19, 2014 at 04:50:39AM +, Iyer, Balaji V wrote:
> I have answered your questions below. In addition to your changes, I have
> also fixed the issues Aldy pointed out and have answered his questions in
> that thread. With this email I have attached two patches and 2
> change-logs (fo
;r...@redhat.com'
> Subject: Re: [PATCH] _Cilk_for for C and C++
>
> Here are a few things.
>
> > + if (g_expr.value && TREE_CODE (g_expr.value) ==
> C_MAYBE_CONST_EXPR)
> > + {
> > + error_at (input_location, "cannot convert grain to
On Thu, Jan 16, 2014 at 01:18:59PM -0800, Aldy Hernandez wrote:
> I'm not a C++ expert, but my understanding was that in C++ you don't
> need a typedef to use the following structure by name
> (cilk_for_information). So you can just declare "struct
> cilk_for_information {...}" and instantiate it
Here are a few things.
+ if (g_expr.value && TREE_CODE (g_expr.value) == C_MAYBE_CONST_EXPR)
+ {
+ error_at (input_location, "cannot convert grain to long integer.\n");
+ c_parser_skip_to_pragma_eol (parser);
+ }
Remove final period. Also, where's the testcase
On Thu, Jan 16, 2014 at 12:29:44PM -0500, Jason Merrill wrote:
> >+ if (code == CILK_FOR)
> >+{
> >+ top_level_body = push_stmt_list ();
> >+ top_body = begin_omp_parallel ();
> >+}
>
> I wouldn't expect the front end to care that Cilk for is implemented
> using a parallel call;
On 01/08/2014 02:46 PM, Iyer, Balaji V wrote:
+ /* Grain value, only used by _Cilk_for. */
+ tree grain;
Why can't the grain stay as a clause for the gimple form of the loop?
+ if (flag_enable_cilkplus && TREE_CODE (for_stmt) == CILK_FOR)
+{
+ tree it = TREE_VEC_ELT (OMP_FOR_INIT
On Tue, Jan 07, 2014 at 10:11:59PM +, Iyer, Balaji V wrote:
> I used a similar existing one (safelen). Attached, please find 2
> fixed patches for C and C++ along with their changelogs.
But safelen is something completely different, while if I skim
the _Cilk_for docs, the grain is really
t; Cc: 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'; 'Jakub Jelinek'
> > Subject: Re: [PATCH] _Cilk_for for C and C++
> >
> > On 12/17/2013 07:21 PM, Iyer, Balaji V wrote:
> > > The reason why I store it in OMP_FOR_CLAUSE is because OMP clauses
>
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Tuesday, January 7, 2014 3:41 PM
> To: Iyer, Balaji V; 'Jeff Law'; 'Aldy Hernandez'
> Cc: 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'; 'Jakub Jeline
On 12/17/2013 07:21 PM, Iyer, Balaji V wrote:
The reason why I store it in OMP_FOR_CLAUSE is because OMP clauses cannot occur
in _Cilk_for. So adding a new clause seem to be an overkill IMHO. I need a
place to store the grain value and so I chose this spot.
But code expects OMP_FOR_CLAUSES to
>
> > - return (gimple_omp_subcode (g) & GF_OMP_FOR_COMBINED) != 0;
> > + return (gimple_omp_for_kind (g) == GF_OMP_FOR_COMBINED);
>
> I don't really know this code, but this change seems unlikely to be correct.
> Can you explain it?
I really need help on this. I need a new enum type (I call t
On 12/15/2013 07:40 PM, Iyer, Balaji V wrote:
- tree clauses, tree *cclauses)
+ tree clauses_or_grain, tree *cclauses)
Instead of this, please make the grainsize a new type of clause.
- return (gimple_omp_subcode (g) & GF_OMP_FOR_COMBINED) != 0;
+ r
On 12/03/13 06:25, Iyer, Balaji V wrote:
I understand you both now. Let me look into the OMP routines and see what it is
doing and see how I can port it to _Cilk_for.
Thanks. I know it's a bit of a pain, but part what's driving the desire
to share is to reduce the long term maintenance cost
On Tue, Dec 03, 2013 at 02:01:17PM +, Iyer, Balaji V wrote:
> In Cilk_for you don't need to privatize any variables. I need to pass in
> the loop_count, the grain (if the user specifies one), the nested function
> and its context to a Cilk specific function:__cilkrts_cilk_for_64 (or 32).
> The
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, December 3, 2013 8:40 AM
> To: Iyer, Balaji V
> Cc: Jeff Law; Jason Merrill; Aldy Hernandez; gcc-patches@gcc.gnu.org;
> r...@redhat.com
> Subject: Re: [PATCH] _Cilk_for for C and C+
On Tue, Dec 03, 2013 at 01:25:57PM +, Iyer, Balaji V wrote:
> > >> As you can tell, this is not how openmp handles a #pragma omp for loop.
> > >
> > > It's different in detail, but #pragma omp parallel for works very
> > > similarly: it creates a separate function for the body of the loop and
>
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, December 3, 2013 1:30 AM
> 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 17:52, Jason Merrill wrote:
On 11/27/2013 04:14 PM, Iyer, Balaji V wrote:
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
On 11/27/2013 04:14 PM, Iyer, Balaji V wrote:
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 O
On 11/18/13 14:50, Iyer, Balaji V wrote:
Attached, please find a refreshed patches (one for C and 1 for C++). The trunk
was "diffed" after Aldy's check in of pragma simd was in. So, now this patch is
only dependent on _Cilk_spawn and _Cilk_sync (mostly for execution of tests). They ar
> -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
p
On 11/27/13 10:54, Jakub Jelinek wrote:
On Wed, Nov 27, 2013 at 12:48:11PM -0500, Jason Merrill wrote:
On 11/15/2013 02:23 PM, Iyer, Balaji V wrote:
One small thing that I have not done that Jakub and several other have asked me
before is that, there are no tests in c-c++-common for _Cilk_for.
On Wed, Nov 27, 2013 at 12:48:11PM -0500, Jason Merrill wrote:
> On 11/15/2013 02:23 PM, Iyer, Balaji V wrote:
> >One small thing that I have not done that Jakub and several other have asked
> >me before is that, there are no tests in c-c++-common for _Cilk_for. The
> >reason being that the synta
On 11/15/2013 02:23 PM, Iyer, Balaji V wrote:
One small thing that I have not done that Jakub and several other have asked me
before is that, there are no tests in c-c++-common for _Cilk_for. The reason being
that the syntax between C and C++ implementations are different. In C++, the
inductio
On 11/27/2013 12:06 PM, Jason Merrill wrote:
On 11/26/2013 12:23 PM, Iyer, Balaji V wrote:
Did you get a chance to look at my _Cilk_for patch for C?
BTW, I think pinging less than 24 hours after you send the patch is a
bit excessive. :)
Ah, I see, you were pinging the non-C++ parts.
Ja
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 i
On 11/26/2013 12:23 PM, Iyer, Balaji V wrote:
Did you get a chance to look at my _Cilk_for patch for C?
BTW, I think pinging less than 24 hours after you send the patch is a
bit excessive. :)
Jason
a...@redhat.com);
> r...@redhat.com
> Subject: RE: [PATCH] _Cilk_for for C and C++
>
> Hello Everyone,
> Please see my comment below:
>
> > -Original Message-
> > From: Aldy Hernandez [mailto:al...@redhat.com]
> > Sent: Friday, November 15, 2013
On 11/18/2013 04:50 PM, Iyer, Balaji V wrote:
+ int flags = LOOKUP_PROTECT | LOOKUP_ONLYCONVERTING;
Why not LOOKUP_NORMAL? LOOKUP_ONLYCONVERTING isn't relevant in this context.
+ tree exp = build_new_op (EXPR_LOCATION (op1), code, flags, op0, op1,
+ NULL_TREE, NULL,
One small thing that I have not done that Jakub and several other
have asked me before is that, there are no tests in c-c++-common for
_Cilk_for. The reason being that the syntax between C and C++
implementations are different. In C++, the induction variable must be
defined in the initializer (e
On 11/15/13 12:23, Iyer, Balaji V wrote:
This patch is dependent on the following patches:
#pragma simd work (they both share the same parser routines)
I have just committed this to trunk, so it shouldn't be a blocker.
Also, in the past 2 days the #pragma simd parsing has been merged with
t
56 matches
Mail list logo
