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

[Mark Mitchell <mark@codesourcery.com>]

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.

Well, call it what you like.  It's making a guess about when SRA is or
isn't profitable.  It might be a good guess or a bad guess, but it's a
guess, which is why I used the term "heuristic".

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

That's precisely why I wanted some data about that.  Maybe we already
know enough to know that this isn't a good heuristic because we already
know that SRA on bitfields is a big win in lots of cases.  That's fine;
in that case, the patch is not a good thing.

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

That's an interesting idea.  Does anyone else have an idea as to the
best plan here?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713