From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1074 invoked by alias); 28 Nov 2012 10:25:34 -0000 Received: (qmail 1061 invoked by uid 22791); 28 Nov 2012 10:25:33 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_XT X-Spam-Check-By: sourceware.org Received: from mail-oa0-f47.google.com (HELO mail-oa0-f47.google.com) (209.85.219.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Nov 2012 10:25:16 +0000 Received: by mail-oa0-f47.google.com with SMTP id h1so14006378oag.20 for ; Wed, 28 Nov 2012 02:25:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.21.142 with SMTP id v14mr2532778obe.46.1354098316140; Wed, 28 Nov 2012 02:25:16 -0800 (PST) Received: by 10.76.95.202 with HTTP; Wed, 28 Nov 2012 02:25:16 -0800 (PST) In-Reply-To: References: <87k3u3eybu.fsf@talisman.home> <50B4F419.4030804@arm.com> <878v9mdcdl.fsf@talisman.default> Date: Wed, 28 Nov 2012 10:25:00 -0000 Message-ID: Subject: Re: [0/8] Add optabs alternatives for insv, extv and extzv From: Richard Biener To: ramrad01@arm.com Cc: gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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/msg02303.txt.bz2 On Tue, Nov 27, 2012 at 11:45 PM, Ramana Radhakrishnan wrote: > On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford > wrote: >> 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? > > Fixes volatile-bitfields-1.c but appears to break volatile-bitfields-4.c :( . Can arm folks please re-implement strict volatile bitfields in terms of DECL_BIT_FIELD_REPRESENTATIVE as I suggested elsewhere? Thus, adjust stor-layout.c to compute a proper representative honoring strict volatile bitfield semantics? Thanks, Richard. > Ramana > >> >> 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