On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Ramana Radhakrishnan <ramra...@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?
Fixes volatile-bitfields-1.c but appears to break volatile-bitfields-4.c :( . 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