From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 03E99394FC1D for ; Tue, 13 Jul 2021 10:11:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03E99394FC1D Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A46526D; Tue, 13 Jul 2021 03:11:54 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CFF9E3F7D8; Tue, 13 Jul 2021 03:11:53 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener , "Kewen.Lin" , GCC Patches , Segher Boessenkool , Bill Schmidt , richard.sandiford@arm.com Cc: "Kewen.Lin" , GCC Patches , Segher Boessenkool , Bill Schmidt Subject: Re: [RFC/PATCH] vect: Recog mul_highpart pattern References: Date: Tue, 13 Jul 2021 11:11:52 +0100 In-Reply-To: (Richard Biener's message of "Tue, 13 Jul 2021 11:44:35 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 13 Jul 2021 10:11:56 -0000 Richard Biener writes: > On Tue, Jul 13, 2021 at 11:40 AM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote: >> >> >> >> Hi, >> >> >> >> When I added the support for Power10 newly introduced multiply >> >> highpart instrutions, I noticed that currently vectorizer >> >> doesn't try to vectorize multiply highpart pattern, I hope >> >> this isn't intentional? >> >> >> >> This patch is to extend the existing pattern mulhs handlings >> >> to cover multiply highpart. Another alternative seems to >> >> recog mul_highpart operation in a general place applied for >> >> scalar code when the target supports the optab for the scalar >> >> operation, it's based on the assumption that one target which >> >> supports vector version of multiply highpart should have the >> >> scalar version. I noticed that the function can_mult_highpart_p >> >> can check/handle mult_highpart well even without mul_highpart >> >> optab support, I think to recog this pattern in vectorizer >> >> is better. Is it on the right track? >> > >> > I think it's on the right track, using IFN_LAST is a bit awkward >> > in case yet another case pops up so maybe you can use >> > a code_helper instance instead which unifies tree_code, >> > builtin_code and internal_fn? >> > >> > I also notice that can_mult_highpart_p will return true if >> > only vec_widen_[us]mult_{even,odd,hi,lo} are available, >> > but then the result might be less optimal (or even not >> > handled later)? >> > >> > That is, what about adding optab internal functions >> > for [us]mul_highpart instead, much like the existing >> > ones for MULH{R,}S? >> >> Yeah, that's be my preference too FWIW. All uses of MULT_HIGHPART_EXPR >> already have to be guarded by can_mult_highpart_p, so replacing it with >> a directly-mapped ifn seems like a natural fit. (Then can_mult_highpart_p >> should be replaced with a direct_internal_fn_supported_p query.) > > But note can_mult_highpart_t covers use via vec_widen_[us]mult_{even,odd,hi,lo} > but I think this specific pattern should key on [us]mul_highpart only? > > Because vec_widen_* implies a higher VF (or else we might miss vectorizing?)? But wouldn't it be better to do the existing hi/lo/even/odd conversion in gimple, rather than hide it in expand? (Yes, this is feature creep. :-)) Richard