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: [patch] PR32901: handle assignment...(and PR34465 and PR34448)

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.


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