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]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.

	Jakub


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