https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 14 Jun 2016, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509 > > --- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #1) > > It looks like we didn't adjust the bitfield read paths for the mem model > > because in practice it doesn't matter and it may generate larger/slower code > > not to do loads in larger types on some archs. > > It still generates correct (or at least working) code, yeah. > > > Note that we conservatively compute the extent for > > DECL_BIT_FIELD_REPRESENTATIVE > > by prefering smaller modes. There's some ??? in > > finish_bitfield_representative > > and the above remark about tail padding re-use is only implemented via > > prefering > > smaller modes. Thus when adding a 'long foo' after csum_level the > > representative doesn't change to 64bit width but stays at 8bits (both are > > valid from the C++ memory model). > > Smaller modes are slightly better here, they allow more efficient insn > sequences to manipulate the data, esp. on big endian. For example on > PowerPC, on BE, our 16-bit immediates (in e.g. ior) can handle QImode > and HImode, but not DImode; and e.g. the rlwinm insn can handle SImode > but not DImode. In general, with smaller modes you do not need to > worry about preserving the other bits. > > > Note that the proposed simple lowering of bitfield accesses on GIMPLE would > > do accesses of DECL_BIT_FIELD_REPRESENTATIVE and thus in this case use byte > > accesses. > > That would be lovely :-) On my list for GCC 7 ;-) > > I suppose we want to be less conservative about > > DECL_BIT_FIELD_REPRESENTATIVE > > and leave it up to the target how to do the actual accesses. > > Maybe. Always smallest is a good choice for PowerPC at least. Note the middle-end in extract_bit_field says using a larger mode is always better because it is better for CSE (not sure about that argument if you only look at a single stmt).
