On Tue, Mar 04, 2008 at 11:15:00AM -0500, Diego Novillo wrote:
> >fold currently optimizes a.b.c == 0 to BIT_FIELD_REF <a, 8, big-num> & 1
> >for bit field field-decls c. IMHO this is bad because it pessimizes
> >TBAA (needs to use a's alias set, not the underlying integral type
> >alias set) and it "breaks" type correctness as arbitrary structure
> >types appear as operand zero.
>
> Agreed. Unless this was done to fix some target-specific problem, I
> think it should disappear.
Perhaps not in early GIMPLE passes, but we certainly want to lower
bitfield accesses to BIT_FIELD_REFs or something similar before expansion,
otherwise expander and RTL optimization passes aren't able to optimize but
the most trivial cases. GCC generates for bitfields terrible code ATM,
try say:
struct S
{
unsigned int a : 3;
unsigned int b : 3;
unsigned int c : 3;
unsigned int d : 3;
unsigned int e : 3;
unsigned int f : 3;
unsigned int g : 3;
unsigned int h : 11;
} a, b, c;
void foo (void)
{
a.a = b.a | c.a;
a.b = b.b | c.b;
a.c = b.c | c.c;
a.d = b.d | c.d;
a.e = b.e | c.e;
a.f = b.f | c.f;
a.g = b.g | c.g;
a.h = b.h | c.h;
}
which could be optimized into BIT_FIELD_REF <a, 32, 0> = BIT_FIELD_REF <b, 32,
0> | BIT_FIELD_REF <c, 32, 0>;
so something like 3 or 4 instructions, yet we generate 51.
Operating on adjacent bitfield fields is fairly common.
Similarly (and perhaps far more common in the wild) is e.g.
void bar (void)
{
a.a = 1;
a.b = 2;
a.c = 3;
a.d = 4;
a.e = 5;
a.f = 6;
a.g = 7;
a.h = 8;
}
- on x86_64 24 instructions on the trunk, 1 is enough.
RTL is too late to try to optimize this, I've tried that once.
Given combiner's limitation of only trying to combine 3 instructions
at once, we'd need more. So this is something that needs to
be optimized at the tree level, either by having a separate pass
that takes care of it, or by lowering it early enough into something
that the optimizers will handle.
Jakub
