Hi Jakub,
Please see my response below.
Thanks,
Balaji V. Iyer.
> -----Original Message-----
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, May 22, 2013 2:15 AM
> To: Richard Henderson
> Cc: Iyer, Balaji V; 'Joseph S. Myers'; 'Aldy Hernandez'; 'gcc-patches'
> Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
>
> On Tue, May 21, 2013 at 07:57:10PM -0700, Richard Henderson wrote:
> > >+ /* This will create the if statement label. */
> > >+ if_stmt_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
> > >+ void_type_node);
> > >+ DECL_CONTEXT (if_stmt_label[ii]) = current_function_decl;
> > >+ DECL_ARTIFICIAL (if_stmt_label[ii]) = 0;
> > >+ DECL_IGNORED_P (if_stmt_label[ii]) = 1;
> > >+
> > >+ /* This label statement will point to the loop body. */
> > >+ body_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
> > >+ void_type_node);
> > >+ DECL_CONTEXT (body_label[ii]) = current_function_decl;
> > >+ DECL_ARTIFICIAL (body_label[ii]) = 0;
> > >+ DECL_IGNORED_P (body_label[ii]) = 1;
> > >+ body_label_expr[ii] = build1 (LABEL_EXPR, void_type_node,
> > >+ body_label[ii])
> > >;
> > >+
> > >+ /* This will create the exit label, i.e. where the while loop will
> > >branch
> > >+ out of. */
> > >+ exit_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
> > >+ void_type_node);
> > >+ DECL_CONTEXT (exit_label[ii]) = current_function_decl;
> > >+ DECL_ARTIFICIAL (exit_label[ii]) = 0;
> > >+ DECL_IGNORED_P (exit_label[ii]) = 1;
> > >+ exit_label_expr[ii] = build1 (LABEL_EXPR, void_type_node,
> > >exit_label[ii]);
> > >+ }
> >
> > Is there any particular reason why you're open-coding the loop
> > expansion instead of using existing infrastructure like c_finish_loop?
> >
> > Yes, the specific example of c_finish_loop goes against the c++
> > sharing, but it's fairly easy to add new interfaces to c-common.h that
> > are implemented in the two front ends.
>
> Furthermore, do you want to generate just normal loop out of it, or shouldn't
> we generate a #pragma omp simd loop out of it instead?
> Haven't read the spec if array notation guarantees lack of forward/backward
> loop dependencies and what are the restrictions on the calls you can do
> inside of
> array notation. Perhaps the lowering to normal vs. simd loop could depend on
> whether all called functions in the expression are elemental.
What you mentioned is a good performance optimization. It is something I have
planned to do in future. But, the spec does not require the loop (or array
notation expansion) to be vectorized.
>
> Jakub
