From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43898 invoked by alias); 1 Jun 2016 12:41:02 -0000 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 Received: (qmail 43888 invoked by uid 89); 1 Jun 2016 12:41:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Jun 2016 12:41:00 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D6CAA28; Wed, 1 Jun 2016 05:41:27 -0700 (PDT) Received: from localhost (e105548-lin.manchester.arm.com [10.45.32.67]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EF5763F252; Wed, 1 Jun 2016 05:40:57 -0700 (PDT) From: Richard Sandiford To: Bernd Schmidt Mail-Followup-To: Bernd Schmidt ,, richard.sandiford@arm.com Cc: Subject: Re: Remove word_mode hack for split bitfields References: <8760u0evj5.fsf@e105548-lin.cambridge.arm.com> <574D6750.3080303@redhat.com> Date: Wed, 01 Jun 2016 12:41:00 -0000 In-Reply-To: <574D6750.3080303@redhat.com> (Bernd Schmidt's message of "Tue, 31 May 2016 12:28:32 +0200") Message-ID: <87wpm9cc9z.fsf@e105548-lin.cambridge.arm.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-06/txt/msg00037.txt.bz2 Bernd Schmidt writes: > On 05/26/2016 04:36 PM, Richard Sandiford wrote: >> This patch is effectively reverting a change from 1994. The reason >> I think it's a hack is that store_bit_field_1 is creating a subreg >> reference to one word of a field even though it has already proven that >> the field spills into the following word. We then rely on the special >> SUBREG handling in store_split_bit_field to ignore the extent of op0 and >> look inside the SUBREG_REG regardless. I don't see any reason why we can't >> pass the original op0 to store_split_bit_field instead. >> >> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? > > Any observable effects on code generation? Not that I can see. I tried compiling gcc.dg, g++.dg and gcc.c-torture before and after the patch on: aarch64-linux-gnueabi alpha-linux-gnu arm-linux-gnueabi arm-linux-gnueabihf avr-elf bfin-elf c6x-elf cr16-elf cris-elf epiphany-elf fr30-elf frv-linux-gnu ft32-elf h8300-elf ia64-linux-gnu iq2000-elf lm32-elf m32c-elf m32r-elf m68k-linux-gnu mcore-elf microblaze-elf mips-linux-gnu mmix mn10300-elf moxie-rtems msp430-elf nds32le-elf hppa64-hp-hpux11.23 nios2-linux-gnu nvptx-none powerpc-linux-gnu powerpc-eabispe rl78-elf rx-elf s390-linux-gnu sh-linux-gnu sparc-linux-gnu spu-elf tilegx-elf tilepro-elf xstormy16-elf v850-elf vax-netbsdelf visium-elf xtensa-elf x86_64-darwin The only asm differences (apart from timestamps) were a handful of tests for avr-elf: gcc.c-torture/execute/pr53645.s gcc.c-torture/execute/pr65427.s gcc.dg/pr57233.s gcc.dg/torture/pr30665-2.s gcc.dg/tree-ssa/pr23391.s and c6x-elf: gcc.c-torture/compile/pr42956.s gcc.dg/compat/vector-1a_y.s gcc.dg/compat/vector-1b_y.s gcc.dg/torture/vshuf-v8sf.s In all these cases the rtl seems to be the same before reload, but differences in addresses(?) cause different, but equivalent, RA. None of the LRA targets seem to be affected. Thanks, Richard