From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 1807E3945C0E for ; Tue, 13 Jul 2021 09:44:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1807E3945C0E Received: by mail-ej1-x630.google.com with SMTP id go30so13288734ejc.8 for ; Tue, 13 Jul 2021 02:44:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=59FRQQ/QgWeMYxp1e6NFiOkeVTzu0TU+Qe71nNwLOX0=; b=COaFGnHbD17oSGlw29tTBeTixUG3A4bLlqdb7vtLgNieHKeJuh1Hi4/Qci/7TcgA8w jVtOHjwJOo0mlasgVZjzdUeUJhRK6ZHovOHfXY1NZhgaxhbjv94+gJm8TtCk4EsjVDsj +OIsY0YRtUf2J4P5jH8jZAbnhCPq/hQEG1qGG5vVYV2sMq5CUgLP6En1AijNGcAaSEFl vy4Bgb+93zZRyKKF/DAERJsP2lpIeZkB/4PzF8Yg4d+o3kxt55thUEeYoz3hFBzBUHER k299yi/aJzPrdPnoVVEN/OCa31DZ4Tw+ldN2LFIv67ZwiasDfhLB7Sr9rD8Apxzv8eId YbYQ== X-Gm-Message-State: AOAM531vuMkFd7lNn7YifvRfgVBEQ4eCbOF0GxmFMCVWy4tporNmRpTW HAoL2Wxq1NILVEf/m4Nu7PV0ZwTunIBbHcluwv4= X-Google-Smtp-Source: ABdhPJy8ltgzUtEIsCJ8RmkaUualbg7zzaEure1P9T0WGy1D6WCvyEp+rO3+KpJgq0mOaWsRJKM4y8BxHAyHDaBRkXI= X-Received: by 2002:a17:906:e1a:: with SMTP id l26mr4510454eji.129.1626169486106; Tue, 13 Jul 2021 02:44:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 13 Jul 2021 11:44:35 +0200 Message-ID: Subject: Re: [RFC/PATCH] vect: Recog mul_highpart pattern To: Richard Biener , "Kewen.Lin" , GCC Patches , Segher Boessenkool , Bill Schmidt , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_MANYTO, RCVD_IN_DNSWL_NONE, 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 09:44:48 -0000 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?)? Richard. > Thanks, > Richard