From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15243 invoked by alias); 27 Nov 2012 20:22:58 -0000 Received: (qmail 15228 invoked by uid 22791); 27 Nov 2012 20:22:56 -0000 X-SWARE-Spam-Status: No, hits=-3.3 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-wi0-f175.google.com (HELO mail-wi0-f175.google.com) (209.85.212.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 20:22:50 +0000 Received: by mail-wi0-f175.google.com with SMTP id hm11so3874049wib.8 for ; Tue, 27 Nov 2012 12:22:49 -0800 (PST) Received: by 10.216.139.209 with SMTP id c59mr6606950wej.50.1354047769600; Tue, 27 Nov 2012 12:22:49 -0800 (PST) Received: from localhost ([2.28.234.219]) by mx.google.com with ESMTPS id bz12sm4507326wib.5.2012.11.27.12.22.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 12:22:48 -0800 (PST) From: Richard Sandiford To: ramrad01@arm.com Mail-Followup-To: ramrad01@arm.com,gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [0/8] Add optabs alternatives for insv, extv and extzv References: <87k3u3eybu.fsf@talisman.home> <50B4F419.4030804@arm.com> Date: Tue, 27 Nov 2012 20:22:00 -0000 In-Reply-To: <50B4F419.4030804@arm.com> (Ramana Radhakrishnan's message of "Tue, 27 Nov 2012 17:10:49 +0000") Message-ID: <878v9mdcdl.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2012-11/txt/msg02264.txt.bz2 Ramana Radhakrishnan writes: >> Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf. >> Also tested by making sure that there were no changes in assembly >> output for a set of gcc .ii files. On the other hand, the -march=octeon >> output for a set of mips64-linux-gnu gcc .ii files showed the optimisation >> kicking in as hoped. > > This sequence of patches caused a regression in > gcc.target/arm/volatile-bitfields-1.c . I haven't reviewed the patch > stack in great detail yet, but it looks like this sequence of patches > doesn't take the ARM volatile bitfields into account. (193600 is fine, > 193606 is not). Looks like I was wrong to drop the conditions from patch 5. Please could you try the attached? Richard gcc/ * expmed.c (adjust_bit_field_mem_for_reg): Add handling of volatile bitfields. Index: gcc/expmed.c =================================================================== --- gcc/expmed.c 2012-11-27 19:09:18.000000000 +0000 +++ gcc/expmed.c 2012-11-27 19:09:33.314634741 +0000 @@ -372,6 +372,15 @@ adjust_bit_field_mem_for_reg (enum extra bitregion_end, MEM_ALIGN (op0), MEM_VOLATILE_P (op0)); enum machine_mode best_mode; + if (MEM_VOLATILE_P (op0) && flag_strict_volatile_bitfields > 0) + { + while (iter.next_mode (&best_mode)) + if (GET_MODE_SIZE (best_mode) == MEM_SIZE (op0)) + return narrow_bit_field_mem (op0, best_mode, bitsize, bitnum, + new_bitnum); + return NULL_RTX; + } + if (iter.next_mode (&best_mode)) { /* We can use a memory in BEST_MODE. See whether this is true for