From patchwork Tue Oct 30 19:36:03 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 195613 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 B35EF2C0095 for ; Wed, 31 Oct 2012 06:36:14 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1352230575; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Mail-Followup-To:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=RE96WloxbSksZ3f9Ha5z j1kYH+8=; b=mIjSqW62HkRhQVc89anP/BnDh1nGHo0p2qehwoWERS7tWWaMFK1h DaiOnBEGCf4jiDl5PTqu0+nt9u5SYk84TPI18dZITKVLzfVTxbGsBIuUrNwtdHXZ Y0Rt/fYwvVOJQXBigPXkRFzJEp1FEmOzGlr2aKJlVpjMvmo1I07ZaBw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Mail-Followup-To:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=l/4VSzNELRvGUslc3OE/dBaKjR62xlCsPHd83P3no7bgH83X/FOS+EfqijrJaA m4/fYpayfVhWcOUH8eYO9y0RrtZVaZVqjPgaL+ZLT3VaUDyXJLstw74yhy413uX6 Z1ZIu6XwlYF3ANkyBfboRGPMXrTB6cICQK9N99Fz4cxrI=; Received: (qmail 1953 invoked by alias); 30 Oct 2012 19:36:09 -0000 Received: (qmail 1823 invoked by uid 22791); 30 Oct 2012 19:36:08 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL, BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, KHOP_RCVD_TRUST, NML_ADSP_CUSTOM_MED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, TW_XT X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Oct 2012 19:36:02 +0000 Received: by mail-we0-f175.google.com with SMTP id t44so307920wey.20 for ; Tue, 30 Oct 2012 12:36:01 -0700 (PDT) Received: by 10.216.218.105 with SMTP id j83mr16067277wep.164.1351625760908; Tue, 30 Oct 2012 12:36:00 -0700 (PDT) Received: from localhost ([2.26.192.222]) by mx.google.com with ESMTPS id hb6sm15181290wib.7.2012.10.30.12.35.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 12:36:00 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Subject: [7/8] BITS_BIG_ENDIAN vs. (zero_extract (const_int ...) ...) References: <87ip9rixdi.fsf@talisman.home> Date: Tue, 30 Oct 2012 19:36:03 +0000 In-Reply-To: <87ip9rixdi.fsf@talisman.home> (Richard Sandiford's message of "Tue, 30 Oct 2012 19:16:25 +0000") Message-ID: <87objjhhwc.fsf@talisman.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 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 Combine tries to optimise comparisons involving: (zero_extract (const_int X) (const_int 1) (var Y)) and so on BITS_BIG_ENDIAN targets it tries gamely to work out what mode X actually has. At the moment it tries reading the mode from operand 1 of extzv, but that doesn't feel right, since we never use extzv itself with this combination of operands. (We only use it with combinations in which the first zero_extract operand is variable and the third is constant.) And extzv isn't necessarily a good indicator of what a matched zero_extract does, since targets often have matchable zero_extract insns for more than one mode. E.g. powerpc (a BITS_BIG_ENDIAN target) has both SImode and DImode patterns. In practice, all BITS_BIG_ENDIAN targets that have an extzv pattern either have an explicit word_mode operand (e.g. m68k) or leave it void, which make_for_extraction treats as word_mode. Since word_mode is also the default assumption when no extzv pattern is defined, I think it would be more robust to assume/require word_mode across the board (as much as anything can be called robust in this sort of situation). Tested as described in the covering note. OK to install? Richard gcc/ * combine.c (simplify_comparison): If BITS_BIG_ENDIAN, always assume that zero_extracts of const_ints are doing word-sized extractions. Index: gcc/combine.c =================================================================== --- gcc/combine.c 2012-10-29 14:14:36.371315725 +0000 +++ gcc/combine.c 2012-10-29 14:29:26.800313546 +0000 @@ -11154,17 +11154,7 @@ simplify_comparison (enum rtx_code code, && (i = exact_log2 (UINTVAL (XEXP (op0, 0)))) >= 0) { if (BITS_BIG_ENDIAN) - { - enum machine_mode new_mode - = mode_for_extraction (EP_extzv, 1); - if (new_mode == MAX_MACHINE_MODE) - i = BITS_PER_WORD - 1 - i; - else - { - mode = new_mode; - i = (GET_MODE_PRECISION (mode) - 1 - i); - } - } + i = BITS_PER_WORD - 1 - i; op0 = XEXP (op0, 2); op1 = GEN_INT (i);