Re: Constrain valid arguments to BIT_FIELD_REF

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 10, 2008, Richard Guenther <rguenther@suse.de> wrote:

> On Mon, 10 Mar 2008, Alexandre Oliva wrote:
>> The reason SRA generates more IL is *precisely* to get better
>> optimization.  The back-ends don't handle BIT_FIELD_REFs very well.

> So I thought they can do bit-field stores...?  no?

Err...  Sorry, I didn't mean back-ends, I meant middle-end
optimization passes.  Dunno how I managed to mangle one into the
other.

>> There's a lot of code all over the compiler to simplify masking and
>> shifting that, when you use BIT_FIELD_REF, doesn't (and can't)
>> trigger.  BIT_FIELD_REF hides masks and shifts, such that the compiler
>> can't simplify them without lowering them in the first place.  And the
>> lowering is profitable.

> So, how do you recover from shifting and masking to single instruction
> bit-field stores?

You don't.  You don't open code these operations when they apply to
memory.  When they apply to gimple regs AKA pseudos, then you do, and
then various back-ends have combine patterns to recover the relevant
operations.

> It sounds easier to do from BIT_FIELD_REF and BIT_FIELD_EXPR on
> scalars.

It is easier, indeed, but it will take a lot of work to get the same
amount of optimization that we currently get, and, in order to perform
*some* simplifications, you have to either open-code them, or extend
BIT_FIELD_EXPR so as to specify a bit range to extract from the input
and *another* bit range to replace.  Such that you can combine say:

  T.1_0 = BIT_FIELD_REF <x, 5, 3>;
  y_2 = BIT_FIELD_EXPR <y_1, T.1_0, 12, 3>;

into

  y_2 = BIT_FIELD_REPLACE <3, y_1, 12, x, 5>;

With something like this you can eliminate unnecessary duplicate
shifting from x to y, which is one of the various optimizations that
the middle end can perform.  OTOH, such shift redundancy elimination
is unnecessary if a back-end offers efficient extv, extzv and insv
patterns.  But BIT_FIELD_REPLACE could expand to an extv/insv sequence
or an extzv/insv sequence (signedness doesn't matter, since we're
talking about the same number of bits in both cases), and, if such
operations aren't available, in can be expanded as two masks, a single
shift, and an or, rather than three masks and two shifts, which is
what the two-gimple-stmt above would require.


Note that BIT_FIELD_REPLACE supersedes both BIT_FIELD_REF and
BIT_FIELD_EXPR, except for the lvalue meaning of BIT_FIELD_REF:

 BIT_FIELD_REF <A, B, C> could be expressed as say
 BIT_FIELD_REPLACE <C, 0, 0, A, B>
 
and

  BIT_FIELD_EXPR <D, E, F, G> could be expressed as say
  BIT_FIELD_REPLACE <G, D, F, E, 0>

And then, if we were to add another operand for the output, or express
it as an assignment that could have one of the inputs as output, we'd
have complete semantics, and then it would be "just" a matter of
teaching all of the optimization passes that track bits and shifts to
deal with BIT_FIELD_REPLACE.  This would be just as needed for
BIT_FIELD_REF and BIT_FIELD_EXPR anyway, but the fact that this hasn't
been done for BIT_FIELD_REF yet makes me think I shouldn't hold my
breath.

> SRA _does_ pessimize code in some cases.  BIT_FIELD_REF lowering
> will so as well - after all we are in target independent code.

How could it pessimize code?  BIT_FIELD_REF is just an inflexible
shorthand for the operations that end up taking place anyway.  And the
fact that it's inflexible does harm some optimizations that can be
performed with open coding, and that are recognized and performed as a
combined operation if no optimizations apply.  I get a feeling that
you're barking up the wrong tree here, but I can't claim to have
compared in detail every single instance of generated code using
BIT_FIELD_REF or open-coding it.

> But yeah, it's way easier to add things here and there than to
> make some general changes and still keep people happy :(

Yeah, I can agree that making the changes in SRA only wasn't exactly
the best approach.  When I started, I had no idea that open coding was
so necessary, and when I realized it, I had already spent way too much
time on that particular issue, and I didn't get a feeling that I'd get
buy-in for a larger revamp.  Now, since there is a revamp underway, we
might as well do it right, rather than introduce regressions just to
keep things more uniform.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}