[PATCH] Cilk Plus Array Notation for C++

[Iyer, Balaji V]

> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
> owner@gcc.gnu.org] On Behalf Of Jason Merrill
> Sent: Friday, June 28, 2013 9:43 AM
> To: Iyer, Balaji V; Richard Henderson
> Cc: Aldy Hernandez; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Cilk Plus Array Notation for C++
> 

> > +         /* Sometimes, when comma_expr has a function call in it, it will
> > +            typecast it to void.  Find_inv_trees finds those nodes and so
> > +            if it void type, then don't bother creating a new var to hold
> > +            the return value.   */
> > +         if (VOID_TYPE_P (TREE_TYPE (t)))
> > +           new_var = t;
> > +         else
> > +           new_var = get_temp_regvar (TREE_TYPE (t), t);
> 
> I was suggesting
> 
> if (VOID_TYPE_P (TREE_TYPE (t)))
>    {
>      finish_expr_stmt (t);
>      new_var = void_zero_node;
>    }
>

Fixed! 

> On 06/28/2013 12:54 AM, Iyer, Balaji V wrote:
> >             /* If stride and start are of same type and the induction var
> >                is not, convert induction variable to stride's type.  */
> >             if (TREE_TYPE (start) == TREE_TYPE (stride)
> >                 && TREE_TYPE (stride) != TREE_TYPE (var))
> >               {
> >                 st = start;
> >                 str = stride;
> >                 v = build_c_cast (loc, TREE_TYPE (str), var);
> >               }
> >             else if (TREE_TYPE (start) != TREE_TYPE (stride))
> >               {
> >                 /* If we reach here, then the stridje and start are of
> >                    different types, and so it doesn't really matter what
> >                    the induction variable type is, convert everything to
> >                    integer.  The reason why we pick an integer
> >                    instead of something like size_t is because the stride
> >                    and length can be + or -.  */
> >                 st = build_c_cast (loc, ptrdiff_type_node, start);
> >                 str = build_c_cast (loc, ptrdiff_type_node, stride);
> >                 v = build_c_cast (loc, ptrdiff_type_node, var);
> >               }
> >             else
> >               {
> >                 st = start;
> >                 str = stride;
> >                 v = var;
> >               }
> 
> I still think that what you want is to unconditionally convert start and stride to
> ptrdiff_t, either here or in build_array_notation_ref.
> 

Ok. I made the cast unconditional here. 

> > +           tree ii_tree = array_exprs[ii][jj];
> > +           (*node)[ii][jj].is_vector = true;
> > +           (*node)[ii][jj].value = ARRAY_NOTATION_ARRAY (ii_tree);
> > +           (*node)[ii][jj].start = ARRAY_NOTATION_START (ii_tree);
> > +           (*node)[ii][jj].length =
> > +             fold_build1 (CONVERT_EXPR, integer_type_node,
> > +                          ARRAY_NOTATION_LENGTH (ii_tree));
> > +           (*node)[ii][jj].stride =
> > +             fold_build1 (CONVERT_EXPR, integer_type_node,
> > +                          ARRAY_NOTATION_STRIDE (ii_tree));
> 
> I still don't understand what the purpose of cilkplus_an_parts is; it seems to have
> exactly the same information as the ARRAY_NOTATION_REF, so you might as
> well keep the array of ARRAY_NOTATION_REF instead of copying it into an array
> of cilkplus_an_parts.
> 

Well, it is mainly for ease of book-keeping. For example, if I have A[0:10][5:12] It is stored in ARRAY_NOTATION_REF like this:

<ARRAY_NOTATION_REF  <ARRAY_NOTATION_REF < 0, 10, 1>, 5, 12, 1>>

Now, if we take a simple polynomial example: A[0:10][5:12] + B[7:10][6:12:2]), we have something like this:

<PLUS_EXPR <ARRAY_NOTATION_REF < ARRAY_NOTATION_REF < 0, 10, 1>, 5, 12, 1>>, <ARRAY_NOTATION_REF<ARRAY_NOTATION_REF < 7, 10, 1>, 6, 12, 2>>>

Now, if we store this  PLUS_EXPR in the cilkplus_an_parts, we get something like this:

Node[0][0].start = 0
Node[0][0].length = 10
Node[0][0].stride = 1

Node[0][1].start = 5
Node[0][1].length = 12
Node[0][1].stride = 1

Node[1][0].start = 7
Node[1][0].length = 10
Node[1][0].stride = 1

Node[1][1].start = 6
Node[1][1].length = 12
Node[1][1].stride = 2

Now, if I have to do checking (e.g. make sure all the lengths are same across the rank), it is much easier for me to go through this set of size X rank arrays, than to recursively walk through the PLUS_EXPR and extract all the length values and check them. Also, if I have to add more features to array notations at a later time, this I feel is a lot more easier and straight-forward. In future, it something needs to be debugged, this table-like approach is a lot more simpler for me. Now, if we add things like a function call into the mix, then things get a bit more complicated for me.

Honestly, I don't think it adds that much memory overhead or dynamic code-footprint, and I free all the memory I allocated at the end of the function call.

> 
> > +       stride = RECUR (ARRAY_NOTATION_STRIDE (t));
> > +       if (!cilkplus_an_triplet_types_ok_p (loc, start_index, length, stride,
> > +                                            TREE_TYPE (op1)))
> > +         RETURN (error_mark_node);
> 
> You don't need to check the triplet types in tsubst, since you're checking them in
> build_array_notation_ref.
> 

Fixed!

So, is this OK for trunk?

> Jason

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130628/d6c333a3/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130628/d6c333a3/attachment-0001.txt>