On Fri, Apr 27, 2012 at 10:29 AM, 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.
But won't it re-introduce bugs like PR52080, 52097 or 48124? Also the proper place for this optimization is lowering and CSEing of bit-field loads (not that this lowering already exists). Well, I'm obviously biased here - fold doing this kind of transform looks out-of-place. Richard. > Jakub
