This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [0/8] Add optabs alternatives for insv, extv and extzv
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: ramrad01 at arm dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 27 Nov 2012 20:22:46 +0000
- Subject: Re: [0/8] Add optabs alternatives for insv, extv and extzv
- References: <87k3u3eybu.fsf@talisman.home> <50B4F419.4030804@arm.com>
Ramana Radhakrishnan <ramrad01@arm.com> 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