[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[rguenther at suse dot de]

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