I mis-spelled the org as og and thus the email got bounced. So, here it is
again.
Thanks,
Balaji V. Iyer.
-Original Message-
From: Iyer, Balaji V
Sent: Thursday, March 20, 2014 4:34 PM
To: 'Jakub Jelinek'
Cc: gcc-patc...@gcc.gnu.og
Subject: RE: [PING] [PATCH] _Cilk_for for C and C
'
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, February 20, 2014 11:38 PM
To: Jakub Jelinek
Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez';
'gcc-patches@gcc.gnu.org
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
'
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 PM
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 hope
-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...@redhat.com'
Subject: Re: [PING] [PATCH] _Cilk_for for C and C
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 the
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-int (D.2885, i); ...
retval.1 = operator-int
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
-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...@redhat.com'
Subject: Re: [PING] [PATCH] _Cilk_for for C and C
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,
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++).
It
'
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
requested (model _Cilk_for like a #pragma omp parallel for). Along with this,
I have also attached two
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 both
] [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: Iyer, Balaji V
Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez';
'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'
Subject: Re
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
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
-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
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 Jelinek [mailto:ja...@redhat.com]
Sent: Friday, January 24, 2014 2:42 PM
To: Iyer, Balaji V
Cc
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
: 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 as you are fearing, at most a few hours of work
to get it right, and well worth doing. So
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 really
-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'
Subject: Re: [PATCH] _Cilk_for for C and C++
On Thu, Jan 23
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 (for C
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...@redhat.com'
Subject: Re: [PATCH] _Cilk_for for C and C
to you.
Thanks,
Balaji V. Iyer.
-Original Message-
From: Aldy Hernandez [mailto:al...@redhat.com]
Sent: Thursday, January 16, 2014 4:19 PM
To: Iyer, Balaji V; Jakub Jelinek
Cc: Jason Merrill; 'Jeff Law'; 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'
Subject: Re: [PATCH] _Cilk_for for C
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 with
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 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; can't we
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 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
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
-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 Jelinek'
Subject: Re: [PATCH] _Cilk_for for C and C++
On 12/17/2013
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
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
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;
+
- 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 this:
-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
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
then
-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
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
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 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
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
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
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
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
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 syntax
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
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
-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
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 are
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
Hi Jeff et al.,
Did you get a chance to look at my _Cilk_for patch for C?
Thanks,
Balaji V. Iyer.
-Original Message-
From: Iyer, Balaji V
Sent: Monday, November 18, 2013 4:51 PM
To: Aldy Hernandez
Cc: gcc-patches@gcc.gnu.org; Jeff Law; Jason Merrill (ja...@redhat.com);
r
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,
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
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
56 matches
Mail list logo
