From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57567 invoked by alias); 17 Jul 2019 09:38:12 -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 57552 invoked by uid 89); 17 Jul 2019 09:38:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jul 2019 09:38:10 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2919230B9BF7; Wed, 17 Jul 2019 09:38:09 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-236.ams2.redhat.com [10.36.116.236]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A462719C78; Wed, 17 Jul 2019 09:38:08 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x6H9c5pE008196; Wed, 17 Jul 2019 11:38:06 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x6H9c21j008195; Wed, 17 Jul 2019 11:38:02 +0200 Date: Wed, 17 Jul 2019 10:18:00 -0000 From: Jakub Jelinek To: "Kewen.Lin" Cc: GCC Patches , Richard Biener , richard.sandiford@arm.com, Segher Boessenkool , Bill Schmidt Subject: Re: [PATCH, rs6000] Support vrotr3 for int vector types Message-ID: <20190717093802.GF2125@tucnak> Reply-To: Jakub Jelinek References: <232a38b1-76c2-476d-1be0-a1958e5624bb@linux.ibm.com> <20190715085929.GO2125@tucnak> <32f89c4f-cd2d-a7bd-16d2-26fed6bb5f56@linux.ibm.com> <27be90e6-4beb-5c4c-a163-9b136490d783@linux.ibm.com> <20190717084211.GC2125@tucnak> <3a4d20e2-a586-a957-0baf-92f2ef4f7a8a@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a4d20e2-a586-a957-0baf-92f2ef4f7a8a@linux.ibm.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01160.txt.bz2 On Wed, Jul 17, 2019 at 05:22:38PM +0800, Kewen.Lin wrote: > Good question, the vector rotation for byte looks like (others are similar): > > vrlb VRT,VRA,VRB > do i=0 to 127 by 8 > sh = (VRB)[i+5:i+7] > VRT[i:i+7] = (VRA)[i:i+7] <<< sh > end > > It only takes care of the counts from 0 to prec-1 (inclusive) [log2(prec) bits] > So it's fine even operands[2] are zero or negative. > > Take byte as example, prec is 8. > - rot count is 0, then minus res gets 8. (out of 3 bits range), same as 0. > - rot count is 9, then minus res gets -1. (3 bits parsed as 7), the original > rot count 9 was parsed as 1 (in 3 bits range). > - rot count is -1, then minus res gets 9, (3 bits parsed as 1), the original > rot count was parsed as 7 (in 3 bits range). > > It's a good idea to just use negate! Thanks!! Ok, so the hw for the vectors truncates, the question is how happy will the RTL generic code with that. rs6000 defines SHIFT_COUNT_TRUNCATED to 0, so the generic code can't assume there is a truncation going on. Either it will punt some optimizations when it sees say negative or too large shift/rotate count (that is the better case), or it might just assume there is UB. As the documentation says, for zero SHIFT_COUNT_TRUNCATED there is an option of having a pattern with the truncation being explicit, so in your case *vrotl3_and or similar that would have an explicit AND on the shift operand with say {7, 7...} vector for the byte shifts etc. but emit in the end identical instruction to vrotl3 and use the MINUS + that pattern for vrotr3. If the rotate argument is CONST_VECTOR, you can of course just canonicalize, i.e. perform -operands[2] & mask, fold that into constant and keep using vrotl3 in that case. Jakub