Hi! On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote: > > > > GET_MODE_BITSIZE (lmode)« (8 bits). (With the current sources, lmode is > > > > VOIDmode.) > > > > > > > > Is emmitting »BIT_FIELD_REF <*common, 32, 0> & 255« wrong in this case, > > > > or should a later optimization pass be able to figure out that > > > > »BIT_FIELD_REF <*common, 32, 0> & 255« is in fact the same as > > > > common->code, and then be able to conflate these? Any suggestions > > > > where/how to tackle this? > > > > > > The BIT_FIELD_REF is somewhat of a red-herring. It is created by > > > fold-const.c > > > in optimize_bit_field_compare, code that I think should be removed > > > completely. > > > Or it needs to be made aware of strict-volatile bitfield and C++ memory > > > model > > > details. > > I'd actually very much prefer the latter, just disable > optimize_bit_field_compare for strict-volatile bitfield mode and when > avoiding load data races in C++ memory model (that isn't going to be > default, right?). This optimization is useful, and it is solely about > loads, so even C++ memory model usually shouldn't care.
I can't comment on the C++ memory model bits, but I have now tested the
following patch (fixes the issue for SH, no regressions for ARM, x86):
gcc/
* fold-const.c (optimize_bit_field_compare): Abort early in the strict
volatile bitfields case.
Index: fold-const.c
===================================================================
--- fold-const.c (revision 186856)
+++ fold-const.c (working copy)
@@ -3342,6 +3342,11 @@ optimize_bit_field_compare (location_t loc, enum t
tree mask;
tree offset;
+ /* 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;
+
/* Get all the information about the extractions being done. If the bit size
if the same as the size of the underlying object, we aren't doing an
extraction at all and so can do nothing. We also don't want to
Grüße,
Thomas
pgpj1F9xnVycw.pgp
Description: PGP signature
