Fix asymmetric volatile handling in optimize_bit_field_compare

Bernd Edlinger bernd.edlinger@hotmail.de
Fri Oct 18 12:07:00 GMT 2013


Hello Richard,

I see it the same way.

The existing code in optimize_bit_field_compare looks wrong. It is very asymmetric,
and handles lvolatilep and rvolatilep differently. And the original handling of
flag_strict_volatile_bitfields also was asymmetric.

However this optimize-bit-field-compare check at the beginning of that function was not
introduced because of volatile issues I think:

There was a discussion in April 2012 on this thread: "Continue strict-volatile-bitfields fixes"
 
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01094.html
 
The result was that this optimization seems to break other possible optimizations later on,
when -fstrict-volatile-bitfields was enabled on the SH target. Even when the bit fields are NOT volatile.
(Of course you should not touch volatile bit fields at all)
 
And this was added to optimize_bit_field_compare as a result:
 
  /* In the strict volatile bitfields case, doing code changes here may prevent
     other optimizations, in particular in a SLOW_BYTE_ACCESS setting.  */
  if (flag_strict_volatile_bitfields> 0)
    return 0;
 
Well, I dont know if that still applies to the trunk, and probably this was the completely wrong way to fix
this issue it here.

Maybe that had to do with the other place in stor-layout.c,
which also could be solved differently.

I think it could be possible to remove the flag_strict_volatile_bitfields special case
also there, and instead use the DECL_BIT_FIELD_TYPE instead of DECL_BIT_FIELD in
get_inner_reference IF we have flag_strict_volatile_bitfields and that field
is really volatile. At least this helped in the portable volatiliy patch.
What do you think?

Anyway, here is my patch for review.

OK for trunk after regression testing?

Thanks
Bernd. 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: changelog-bitfield-compare.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20131018/8ecb011a/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-bitfield-compare.diff
Type: application/octet-stream
Size: 2596 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20131018/8ecb011a/attachment.obj>


More information about the Gcc-patches mailing list