[patch] PR32901: handle assignment...(and PR34465 and PR34448)

Jakub Jelinek jakub@redhat.com
Thu Dec 20 13:56:00 GMT 2007

On Thu, Dec 20, 2007 at 07:44:18AM -0500, Diego Novillo wrote:
> On 12/19/07 07:44, Jakub Jelinek wrote:
> >ATM non-empty CONSTRUCTOR on RHS (unless it is a vector CONSTRUCTOR) is
> >considered invalid GIMPLE.
> I said CONSTRUCTOR, but I really meant BIT_FIELD_REF.  However, I see 
> your point and, yes, this is something we should combine at a later 
> stage.  On our way out of SSA and GIMPLE looks like a good place.

Yeah, as BIT_FIELD_REF is a valid gimple, perhaps just adding some late pass
that would optimize adjacent similar bitfield operations into BIT_FIELD_REF
operations would be worthwhile.  Still combining initializers into
CONSTRUCTORs might be handy.

> Now, how much optimization are we losing here in real life?  I doubt 
> these initializers are often used in hot paths.  So, I don't think 
> there's a lot of urgency in fixing this.  But we should open a PR (if 
> one doesn't exist yet).

If not anything else, it can be sometimes really serious size regression.
Say on that
typedef struct { unsigned int a : 5, b : 5, c : 5, d : 5, e : 5, f : 7; } S;

static S s;

bar (void)
  S t = { 1, 2, 3, 4, 5, 6 };
  s = t;

we are talking about with -Os about 11 .text bytes in 3.4.x and 112 .text bytes
on the trunk.  There are many projects that use bitfields heavily (including
gcc) and the generated code is really abysmal.  Sometimes combiner is able
to reduce some bloat, but often it is not.
We have PR22141 for the non-bitfield initializer stores not being merged
together, I thought we have several PRs about horrible bitfield code, but
can't find them ATM.


More information about the Gcc-patches mailing list