From patchwork Sat Jun 25 08:18:01 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 101951 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 9259EB6F98 for ; Sat, 25 Jun 2011 18:17:42 +1000 (EST) Received: (qmail 27086 invoked by alias); 25 Jun 2011 08:17:37 -0000 Received: (qmail 27078 invoked by uid 22791); 25 Jun 2011 08:17:35 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, TW_CL, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 25 Jun 2011 08:17:15 +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 p5P8HEKx017081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 25 Jun 2011 04:17:14 -0400 Received: from Gift.redhat.com (vpn1-5-135.ams2.redhat.com [10.36.5.135]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5P8HA2W024920; Sat, 25 Jun 2011 04:17:11 -0400 From: Nick Clifton To: aoliva@redhat.com, law@redhat.com, rth@redhat.com Cc: gcc-patches@gcc.gnu.org Subject: RFA; MN10300: Fix AM33 clzsi2 pattern Date: Sat, 25 Jun 2011 09:18:01 +0100 Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi Alex, Hi Jeff, Hi Richard, The clzsi2/bsch patterns in the MN10300 backend do not work. There are two problems - firstly the starting bit-search position for the BSCH instruction is not set. Secondly the BSCH instruction returns the bit position of the highest set bit, not the number of leading zeros. The attached patch fixes both of these problems and shaves about 200 unexpected failures off the gcc testsuite for the AM33 or AM33_2 multilibs. OK to apply ? Cheers Nick gcc/ChangeLog 2011-06-25 Nick Clifton * config/mn10300/mn10300.md (clzsi2): Remove unused const_int 0. (bsch): Remove unused second operand. Initialise bit search starting position. Convert located bit position into a zero count. Index: gcc/config/mn10300/mn10300.md =================================================================== --- gcc/config/mn10300/mn10300.md (revision 175370) +++ gcc/config/mn10300/mn10300.md (working copy) @@ -1812,21 +1812,25 @@ ;; ---------------------------------------------------------------------- (define_expand "clzsi2" - [(parallel [(set (match_operand:SI 0 "register_operand" "") - (unspec:SI [(match_operand:SI 1 "register_operand" "") - (const_int 0)] UNSPEC_BSCH)) + [(parallel [(set (match_operand:SI 0 "register_operand") + (unspec:SI [(match_operand:SI 1 "register_operand")] + UNSPEC_BSCH)) (clobber (reg:CC CC_REG))])] "TARGET_AM33" ) +;; The XOR in the instruction sequence below is there because the BSCH +;; instruction returns the bit number of the highest set bit and we want +;; the number of zero bits above that bit. The AM33 does not have a +;; reverse subtraction instruction, but we can use an xor instead since +;; we know that the top 27 bits are clear. (define_insn "*bsch" - [(set (match_operand:SI 0 "register_operand" "=r") - (unspec:SI [(match_operand:SI 1 "register_operand" "r") - (match_operand:SI 2 "nonmemory_operand" "0")] + [(set (match_operand:SI 0 "register_operand" "=&r") + (unspec:SI [(match_operand:SI 1 "register_operand" "r")] UNSPEC_BSCH)) (clobber (reg:CC CC_REG))] "TARGET_AM33" - "bsch %1,%0" + "clr %0 ; bsch %1, %0; xor 31, %0" ) ;; ----------------------------------------------------------------------