This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Remove word_mode hack for split bitfields
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 01 Jun 2016 13:40:56 +0100
- Subject: Re: Remove word_mode hack for split bitfields
- Authentication-results: sourceware.org; auth=none
- References: <8760u0evj5 dot fsf at e105548-lin dot cambridge dot arm dot com> <574D6750 dot 3080303 at redhat dot com>
Bernd Schmidt <bschmidt@redhat.com> 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