Hi!
On Fri, Sep 04, 2020 at 05:18:49PM +0800, luoxhu wrote:
> On 2020/9/4 15:23, Richard Biener wrote:
> > On Fri, Sep 4, 2020 at 9:19 AM Richard Biener
> > <richard.guent...@gmail.com> wrote:
> >> On Fri, Sep 4, 2020 at 8:38 AM luoxhu <luo...@linux.ibm.com> wrote:
> >>> On 2020/9/4 14:16, luoxhu via Gcc-patches wrote:
> >>>> Another problem is v[n&3]=i and vec_insert(v, i, n) are generating with
> >>>> different gimple code:
> >>>>
> >>>> {
> >>>> _1 = n & 3;
> >>>> VIEW_CONVERT_EXPR<int[4]>(v1)[_1] = i;
> >>>> }
> >>>>
> >>>> vs:
> >>>>
> >>>> {
> >>>> __vector signed int v1;
> >>>> __vector signed int D.3192;
> >>>> long unsigned int _1;
> >>>> long unsigned int _2;
> >>>> int * _3;
> >>>>
> >>>> <bb 2> [local count: 1073741824]:
> >>>> D.3192 = v_4(D);
> >>>> _1 = n_7(D) & 3;
> >>>> _2 = _1 * 4;
> >>>> _3 = &D.3192 + _2;
> >>>> *_3 = i_8(D);
> >>>> v1_10 = D.3192;
> >>>> return v1_10;
> >>>> }
Not the semantics of vec_insert aren't exactly that.. It doesn't modify
the vector in place, it returns a copy with the modification. But yes,
it could/should just use this same VIEW_CONVERT_EXPR(...)[...] thing for
that.
> >> I think what the GCC vector extensions produce is generally better
> >> so wherever "code generation" for vec_insert resides it should be
> >> adjusted to produce the same code. Same for vec_extract.
Yup.
> > Guess altivec.h, dispatching to __builtin_vec_insert. Wonder why it wasn't
> >
> > #define vec_insert(a,b,c) (a)[c]=(b)
> >
> > anyway, you obviously have some lowering of the builtin somewhere in
> > rs6000.c
> > and thus can adjust that.
> >
>
> Yes, altivec.h use that style for all vector functions, not sure why.
Probably simply because pretty much everything in there is just calling
builtins, everything new follows suit. It is contagious ;-)
> But this could be adjusted by below patch during front end parsing,
> which could also generate "VIEW_CONVERT_EXPR<int[4]>(D.3192)[_1] = i;"
> in gimple, then both v[n&3]=i and vec_insert(v, i, n) could use optabs
> in expander:
>
>
> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> index 03b00738a5e..00c65311f76 100644
> --- a/gcc/config/rs6000/rs6000-c.c
> +++ b/gcc/config/rs6000/rs6000-c.c
> /* Build *(((arg1_inner_type*)&(vector type){arg1})+arg2) = arg0. */
> @@ -1654,15 +1656,8 @@ altivec_resolve_overloaded_builtin (location_t loc,
> tree fndecl,
> SET_EXPR_LOCATION (stmt, loc);
> stmt = build1 (COMPOUND_LITERAL_EXPR, arg1_type, stmt);
> }
> -
> - innerptrtype = build_pointer_type (arg1_inner_type);
> -
> - stmt = build_unary_op (loc, ADDR_EXPR, stmt, 0);
> - stmt = convert (innerptrtype, stmt);
> - stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
> - stmt = build_indirect_ref (loc, stmt, RO_NULL);
> - stmt = build2 (MODIFY_EXPR, TREE_TYPE (stmt), stmt,
> - convert (TREE_TYPE (stmt), arg0));
> + stmt = build_array_ref (loc, stmt, arg2);
> + stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt, arg0);
> stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
> return stmt;
> }
You should make a copy of the vector, not modify the original one in
place? (If I read that correctly, heh.) Looks good otherwise.
Segher
