From patchwork Sat Feb 2 08:58:44 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 217642 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 B1DE62C0082 for ; Sat, 2 Feb 2013 19:59:03 +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=1360400345; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: From:To:Mail-Followup-To:Cc:Subject:Date: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=esuMoU7H4OJxFRvlefceRjlpli8=; b=QxBca8AbLHF1Ebb F9PRCrfjRDp4vMX0JDsi9WZSGAcBAHv5UfsmuyqyxAm5hunpcKVFD7OwuNQY0+1U EW839BMzR2Gqd1WHrtiSwOg1L1fzNG8hPa1VQxNhr28dfBRgJGeqjTBJxj2s76bb RewfzPn6YjKgH3rjPf2QiuBZ9/64= 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:X-Received:Received:From:To:Mail-Followup-To:Cc:Subject:Date: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=Bdq9Z+XKV15S0VVhKTdNc1aUxZv4280JecyOo+kwVQgFTr1OSC6c0udyifHC6g bD1p1x3+rhgIZki9VYsfjx1kNhEHpBq+ynVjalF+S4djXGERWslQxHrvEeD3NAyI DjgEqMeJI8R3Va3KtPDrZSeACRk3HD6HwW3Y+bg1VBSfg=; Received: (qmail 16117 invoked by alias); 2 Feb 2013 08:58:56 -0000 Received: (qmail 16095 invoked by uid 22791); 2 Feb 2013 08:58:55 -0000 X-SWARE-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_NO, RCVD_IN_HOSTKARMA_YE, TW_XT X-Spam-Check-By: sourceware.org Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 02 Feb 2013 08:58:49 +0000 Received: by mail-wg0-f43.google.com with SMTP id e12so3547717wge.22 for ; Sat, 02 Feb 2013 00:58:48 -0800 (PST) X-Received: by 10.180.104.196 with SMTP id gg4mr1856652wib.16.1359795527987; Sat, 02 Feb 2013 00:58:47 -0800 (PST) Received: from localhost ([2.26.176.154]) by mx.google.com with ESMTPS id g2sm8481821wiy.0.2013.02.02.00.58.45 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 02 Feb 2013 00:58:46 -0800 (PST) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, ebotcazou@libertysurf.fr, rdsandiford@googlemail.com Cc: ebotcazou@libertysurf.fr Subject: RFA: Fix mips-sde-elf fallout from 4.8 extv/extzv changes Date: Sat, 02 Feb 2013 08:58:44 +0000 Message-ID: <87wqurqegr.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (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 This patch fixes a regression caused by my ext and extzv changes. The original idea was that the extract side could pass the number of significant bits in the structure to get_best_reg_extraction_insn, ignoring any bits higher than the field we're extracting: /* Return true if an instruction exists to access a field of mode FIELDMODE in a register structure that has STRUCT_BITS significant bits. Describe the "best" such instruction in *INSN if so. PATTERN describes the type of insertion or extraction we want to perform. For an insertion, the number of significant structure bits includes all bits of the target. For an extraction, it need only include the most significant bit of the field. Larger widths are acceptable in both cases. */ That still seems correct in itself, but I'd fluffed the call site: if (!MEM_P (op0) && get_best_reg_extraction_insn (&extv, pattern, bitnum + bitsize, tmode)) in two ways: the calculation was wrong for big-endian, and extract_bit_field wouldn't cope with cases where TRULY_NOOP_TRUNCATION was false for the implied truncation. The latter problem triggered an UNPREDICTABLE warning from the GDB simulator on vshuf-v8qi.c for -mips64r2 on mips-sde-elf. It also shows why the truncation optimisation isn't useful for MIPS: anything smaller than a word uses the SImode optabs anyway, and TRULY_NOOP_TRUNCATION makes it wrong to use the SImode optabs on DImode structures. So for 4.8 I think the best thing is simply to pass the full width of the structure. We could revisit it in later releases if another target would find it useful. Tested on x86_64-linux-gnu and mips-sde-elf. OK to install? Richard gcc/ * expmed.c (extract_bit_field_1): Pass the full width of the structure to get_best_reg_extraction_insn. Index: gcc/expmed.c =================================================================== --- gcc/expmed.c 2013-02-02 08:46:38.031991259 +0000 +++ gcc/expmed.c 2013-02-02 08:57:04.726958347 +0000 @@ -1569,7 +1569,11 @@ extract_bit_field_1 (rtx str_rtx, unsign enum extraction_pattern pattern = unsignedp ? EP_extzv : EP_extv; extraction_insn extv; if (!MEM_P (op0) - && get_best_reg_extraction_insn (&extv, pattern, bitnum + bitsize, + /* ??? We could limit the structure size to the part of OP0 that + contains the field, with appropriate checks for endianness + and TRULY_NOOP_TRUNCATION. */ + && get_best_reg_extraction_insn (&extv, pattern, + GET_MODE_BITSIZE (GET_MODE (op0)), tmode)) { rtx result = extract_bit_field_using_extv (&extv, op0, bitsize, bitnum,