From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 33ACB3857C73; Fri, 4 Sep 2020 10:23:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 33ACB3857C73 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 084ANvxs000934; Fri, 4 Sep 2020 05:23:57 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 084ANvTi000933; Fri, 4 Sep 2020 05:23:57 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 4 Sep 2020 05:23:57 -0500 From: Segher Boessenkool To: luoxhu Cc: Richard Biener , GCC Patches , David Edelsohn , Bill Schmidt , linkw@gcc.gnu.org Subject: Re: [PATCH] rs6000: Expand vec_insert in expander instead of gimple [PR79251] Message-ID: <20200904102357.GF28786@gate.crashing.org> References: <53017f5c-d81b-6fe2-6c5d-1496249313f1@linux.ibm.com> <599b6eff-42fc-82ef-c822-f3502997798a@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 10:23:59 -0000 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 > > wrote: > >> On Fri, Sep 4, 2020 at 8:38 AM luoxhu 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(v1)[_1] = i; > >>>> } > >>>> > >>>> vs: > >>>> > >>>> { > >>>> __vector signed int v1; > >>>> __vector signed int D.3192; > >>>> long unsigned int _1; > >>>> long unsigned int _2; > >>>> int * _3; > >>>> > >>>> [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(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