This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [0/8] Add optabs alternatives for insv, extv and extzv

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 
> . 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?


	* expmed.c (adjust_bit_field_mem_for_reg): Add handling of volatile

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]