This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Don't completely scalarize a record if it contains bit-field (PR tree-optimization/45144)

On Fri, Jul 30, 2010 at 7:53 PM, Jakub Jelinek <> wrote:
> On Fri, Jul 30, 2010 at 10:11:42AM -0700, Mark Mitchell wrote:
>> To me, Jie's change seems like a plausible heuristic within the current
>> infrastructure. ?I'm all for building new infrastructure when
>> possible/necessary, but I don't think we should prevent these kinds of
>> tweaks to heuristics just because we can think of another way of doing
>> things. ?To me, the question ought to be "does this make the compiler
>> better for users?"
> I wouldn't call it tweak to heuristics, it looks to me like an ugly hack.
> In many cases the SRA of bitfields is very desirable, especially for apps
> that use bitfields heavily like Linux kernel. ?I remember Alex spending
> quite some time improving SRA to handle bitfields more efficiently,
> and this hack just disables it altogether.
> What we IMHO need is a pass late in the gimple pipeline which will
> optimize adjacent bitfield operations and lower to BIT_FIELD_REF ops
> or something similar, because bitfield ops are too hard to be handled
> efficiently after the expansion. ?Combiner helps sometimes, but for many
> bit field ops the 3 insn limit is too limiting.
> Such pass could help with many more things than just what has been created
> for bitfields by SRA in some cases, consider say:
> struct A { unsigned short h; int i : 4, j : 4, k : 4, l : 4; } a, b, c;
> void
> foo (void)
> {
> ?a.i |= 5; a.j = 3; a.k &= 2; a.l = 8;
> ?b.i = c.i; b.j = c.j; b.k = c.k; b.l = c.l;
> }
> which on say i?86/x86_64 can be optimized as roughly:
> ?((unsigned short *)&a)[1] = (((unsigned short *)&a)[1] & 0x20a) | 0x8035;
> ?((unsigned short *)&b)[1] = ((unsigned short *)&c)[1];
> (of course in some alias friendly way).
> See e.g. PR37135/PR22121/PR42172.

Note that on the old mem-ref branch I lowered bit-field references very
early, but people complained that we eventually loose the targets
ability to directly perform bitfield stores.

Basically I lowered each bitfield access (with bitfield access I name
those using a COMPONENT_REF with a FIELD_DECL that has
DECL_BIT_FIELD set) to either a load of the underlying type
plus a BIT_FIELD_REF on the loaded scalar, or a load of the underlying
type plus a BIT_FIELD_EXPR (new code, which inserts bits into
a scalar) plus a store of the underlying type.  CSE and DSE handled
the redundant loads and stores very nicely and BIT_FIELD_EXPRs
and BIT_FIELD_EXPRs were easily combined.

Now instead of lowering very early or very late as Jakub suggests we
can drive (and perform) that lowering in SRA.  For example by
simply walking through its list of accesses and combine them.


> ? ? ? ?Jakub

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]