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 :-)
> 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.
> Widening the representative generates
>
> __skb_decr_checksum_unnecessary:
> ld 9,8(3)
> addi 10,9,3
> rldicr 9,9,0,61
> rldicl 10,10,0,62
> or 9,9,10
> std 9,8(3)
> blr
Making all accesses use QImode yields
__skb_decr_checksum_unnecessary:
lbz 9,8(3)
addi 10,9,3
rlwinm 9,9,0,0,29
rlwinm 10,10,0,30,31
or 9,9,10
stb 9,8(3)
blr
(the rlwinm's and the or could be a rlwimi together, not sure why they
aren't merged)
and on BE it gives
.L.__skb_decr_checksum_unnecessary:
lbz 9,8(3)
srwi 10,9,6
rlwinm 9,9,0,26,31
addi 10,10,3
rlwinm 10,10,6,24,25
or 9,9,10
stb 9,8(3)
blr
which could be just
lbz 9,8(3)
addi 9,9,192
stb 9,8(3)
blr
