From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77842 invoked by alias); 18 Jul 2019 07:01:27 -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 77824 invoked by uid 89); 18 Jul 2019 07:01:26 -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=ATM 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; Thu, 18 Jul 2019 07:01:21 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 739F930821C2; Thu, 18 Jul 2019 07:01:20 +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 F27D15DE68; Thu, 18 Jul 2019 07:01:19 +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 x6I71GJB010946; Thu, 18 Jul 2019 09:01:17 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x6I71DwV010945; Thu, 18 Jul 2019 09:01:13 +0200 Date: Thu, 18 Jul 2019 07:03:00 -0000 From: Jakub Jelinek To: Segher Boessenkool Cc: Richard Biener , "Kewen.Lin" , GCC Patches , Richard Sandiford , Bill Schmidt Subject: Re: [RFC] Consider lrotate const rotation in vectorizer Message-ID: <20190718070113.GK2125@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> <20190717105432.GG2125@tucnak> <20190717170032.GO20882@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190717170032.GO20882@gate.crashing.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01223.txt.bz2 On Wed, Jul 17, 2019 at 12:00:32PM -0500, Segher Boessenkool wrote: > I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED > for rotates? Not all immediates are valid of course, but that is a > separate issue. Well, we'd need to double check all the hw rotate instructions on all the targets to be sure. As for the current GCC code, SHIFT_COUNT_TRUNCATED value is used even for rotates at least in combine.c, expmed.c and simplify-rtx.c and in optabs.c through targetm.shift_truncation_mask, but e.g. in cse.c is used only for shifts and not rotates. And speaking of optabs.c, it already has code to emit the other rotate if one rotate isn't supported, the: /* If we were trying to rotate, and that didn't work, try rotating the other direction before falling back to shifts and bitwise-or. */ if (((binoptab == rotl_optab && (icode = optab_handler (rotr_optab, mode)) != CODE_FOR_nothing) || (binoptab == rotr_optab && (icode = optab_handler (rotl_optab, mode)) != CODE_FOR_nothing)) && is_int_mode (mode, &int_mode)) { optab otheroptab = (binoptab == rotl_optab ? rotr_optab : rotl_optab); hunk in there, just it is limited to scalar rotates ATM rather than vector ones through is_int_mode. So I bet the problem with the vector shifts is just that tree-vect-generic.c support isn't there. And the above mentioned code actually emits the newop1 = expand_binop (GET_MODE (op1), sub_optab, gen_int_mode (bits, GET_MODE (op1)), op1, NULL_RTX, unsignedp, OPTAB_DIRECT); as the fallback, rather than masking of negation with some mask, so if there is some target that doesn't truncate the rotate count, it will be problematic with variable rotate by 0. And note that the other rotate code explicitly uses targetm.shift_truncation_mask. Jakub