Re: Constrain valid arguments to BIT_FIELD_REF

[Richard Guenther <rguenther at suse dot de>]

On Tue, 4 Mar 2008, Jakub Jelinek wrote:

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

Sure.  With 4.3 SRA tries to do this.  With the MEM_REF lowering I have
we optimize the above to

foo ()
{
  unsigned int MEML.2;
  unsigned int MEML.1;
  unsigned int MEML.0;

<bb 2>:
  MEML.0 = MEM <unsigned int {0}, &b>;
  MEML.1 = MEM <unsigned int {0}, &c>;
  MEML.2 = MEM <unsigned int {0}, &a>;

(load all three words once)

  MEM <unsigned int {0}, &a> = BIT_FIELD_EXPR <BIT_FIELD_EXPR 
<BIT_FIELD_EXPR <BIT_FIELD_EXPR <BIT_FIELD_EXPR <BIT_FIELD_EXPR 
<BIT_FIELD_EXPR <BIT_FIELD_EXPR <MEML.2, (<unnamed-unsigned:3>) ((unsigned 
char) BIT_FIELD_REF <MEML.1, 3, 0> | (unsigned char) BIT_FIELD_REF 
<MEML.0, 3, 0>), 3, 0>, (<unnamed-unsigned:3>) ((unsigned char) 
BIT_FIELD_REF <MEML.1, 3, 3> | (unsigned char) BIT_FIELD_REF <MEML.0, 3, 
3>), 3, 3>, (<unnamed-unsigned:3>) ((unsigned char) BIT_FIELD_REF <MEML.1, 
3, 6> | (unsigned char) BIT_FIELD_REF <MEML.0, 3, 6>), 3, 6>, 
(<unnamed-unsigned:3>) ((unsigned char) BIT_FIELD_REF <MEML.1, 3, 9> | 
(unsigned char) BIT_FIELD_REF <MEML.0, 3, 9>), 3, 9>, 
(<unnamed-unsigned:3>) ((unsigned char) BIT_FIELD_REF <MEML.1, 3, 12> | 
(unsigned char) BIT_FIELD_REF <MEML.0, 3, 12>), 3, 12>, 
(<unnamed-unsigned:3>) ((unsigned char) BIT_FIELD_REF <MEML.1, 3, 15> | 
(unsigned char) BIT_FIELD_REF <MEML.0, 3, 15>), 3, 15>, 
(<unnamed-unsigned:3>) ((unsigned char) BIT_FIELD_REF <MEML.1, 3, 18> | 
(unsigned char) BIT_FIELD_REF <MEML.0, 3, 18>), 3, 18>, 
(<unnamed-unsigned:11>) ((short unsigned int) BIT_FIELD_REF <MEML.1, 11, 
21> | (short unsigned int) BIT_FIELD_REF <MEML.0, 11, 21>), 11, 21>;
  return;

}

TER makes a mess out of the expression and obviously we miss some
expression combining here (I only have trivial constant folding
implemented for BIT_FIELD_EXPR right now).

Richard.