From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24854 invoked by alias); 10 May 2013 14:54:07 -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 24810 invoked by uid 89); 10 May 2013 14:54:01 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 10 May 2013 14:54:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4AErxG0019312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 May 2013 10:53:59 -0400 Received: from zalov.cz (vpn-59-91.rdu2.redhat.com [10.10.59.91]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4AErw9m010261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 May 2013 10:53:59 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r4AErvXA004241 for ; Fri, 10 May 2013 16:53:57 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r4AEruE1004240 for gcc-patches@gcc.gnu.org; Fri, 10 May 2013 16:53:56 +0200 Date: Fri, 10 May 2013 14:54:00 -0000 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix up rotate expansion Message-ID: <20130510145355.GR1377@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-05/txt/msg00519.txt.bz2 Hi! Our rotate expansion if rotate optab isn't present for the respective mode looks unsafe for rotations by variable count if that count could be 0, because then it invokes right or left shift by bitsize. While on most targets the hw will probably do the right thing (it is fine if x << 32 will either yield x or 0, in both cases that ored together with x >> 0 aka x will still yield x), perhaps gcc could try to optimize based on the fact that undefined behavior can't happen, so IMHO it is better to generate a safer sequence. Ok for trunk? 2013-05-10 Jakub Jelinek * expmed.c (expand_shift_1): For rotations by const0_rtx just return shifted. Use (-op1) & (prec - 1) as other_amount instead of prec - op1. --- gcc/expmed.c.jj 2013-05-07 10:26:46.000000000 +0200 +++ gcc/expmed.c 2013-05-10 11:54:34.659987038 +0200 @@ -2166,7 +2166,8 @@ expand_shift_1 (enum tree_code code, enu { /* If we have been unable to open-code this by a rotation, do it as the IOR of two shifts. I.e., to rotate A - by N bits, compute (A << N) | ((unsigned) A >> (C - N)) + by N bits, compute + (A << N) | ((unsigned) A >> ((-N) & (C - 1))) where C is the bitsize of A. It is theoretically possible that the target machine might @@ -2181,14 +2182,22 @@ expand_shift_1 (enum tree_code code, enu rtx temp1; new_amount = op1; - if (CONST_INT_P (op1)) + if (op1 == const0_rtx) + return shifted; + else if (CONST_INT_P (op1)) other_amount = GEN_INT (GET_MODE_BITSIZE (mode) - INTVAL (op1)); else - other_amount - = simplify_gen_binary (MINUS, GET_MODE (op1), - GEN_INT (GET_MODE_PRECISION (mode)), - op1); + { + other_amount + = simplify_gen_unary (NEG, GET_MODE (op1), + op1, GET_MODE (op1)); + other_amount + = simplify_gen_binary (AND, GET_MODE (op1), + other_amount, + GEN_INT (GET_MODE_PRECISION (mode) + - 1)); + } shifted = force_reg (mode, shifted); Jakub