> -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
nd them 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'; '
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
35 matches
Mail list logo
