From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73150 invoked by alias); 18 Jul 2019 06:06:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 73142 invoked by uid 89); 18 Jul 2019 06:06:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Jul 2019 06:06:02 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6I63dlm041541 for ; Thu, 18 Jul 2019 02:06:00 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ttg4g6gg8-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 18 Jul 2019 02:06:00 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 18 Jul 2019 07:05:58 +0100 Received: from b06avi18626390.portsmouth.uk.ibm.com (9.149.26.192) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 18 Jul 2019 07:05:56 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x6I65fvr37487016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Jul 2019 06:05:41 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 44D8CA4040; Thu, 18 Jul 2019 06:05:55 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 744B2A4057; Thu, 18 Jul 2019 06:05:53 +0000 (GMT) Received: from kewenlins-mbp.cn.ibm.com (unknown [9.200.147.99]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 18 Jul 2019 06:05:53 +0000 (GMT) Subject: Re: [RFC] Consider lrotate const rotation in vectorizer To: Richard Biener Cc: GCC Patches , Jakub Jelinek , Richard Sandiford , Segher Boessenkool , Bill Schmidt References: <232a38b1-76c2-476d-1be0-a1958e5624bb@linux.ibm.com> <20190715085929.GO2125@tucnak> <32f89c4f-cd2d-a7bd-16d2-26fed6bb5f56@linux.ibm.com> From: "Kewen.Lin" Date: Thu, 18 Jul 2019 06:28:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit x-cbid: 19071806-0028-0000-0000-000003859137 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19071806-0029-0000-0000-00002445B967 Message-Id: <0e663e03-de48-afe3-8991-ff4159d22b5e@linux.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01220.txt.bz2 on 2019/7/17 下午6:37, Richard Biener wrote: > On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin wrote: >> >> Hi all, >> >> Based on the previous comments (thank you!), I tried to update the >> handling in expander and vectorizer. Middle-end optimizes lrotate >> with const rotation count to rrotate all the time, it makes vectorizer >> fail to vectorize if rrotate isn't supported on the target. We can at >> least teach it on const rotation count, the cost should be the same? >> At the same time, the expander already tries to use the opposite >> rotation optable for scalar, we can teach it to deal with vector as well. >> >> Is it on the right track and reasonable? > > So you're basically fixing this up in the expander. I think on > the GIMPLE level you then miss to update tree-vect-generic.c? > Thanks, I will update it. Another question on variable rotation number, where is the best place I can add additional cost in vectorizer (for negate + possible maskgen/and)? Or to avoid this, transform the stmt to several stmts with opposite direction before vectorizer? > I'm not sure if it makes sense to have both LROTATE_EXPR and > RROTATE_EXPR on the GIMPLE level then (that CPUs only > support one direction is natural though). So maybe simply get > rid of one? One maybe impractical idea to have ROTATE_EXPR to unify and use positive or negative for the direction? > Its semantics are also nowhere documented > (do we allow negative rotation amounts? how are > non-mode-precision entities rotated? etc.). > I think negative rotation amount is ok, not sure non-mode-prec, it's a good point we should guard it when would like to use the opposite direction. Thanks, Kewen