Re: Constrain valid arguments to BIT_FIELD_REF

[Alexandre Oliva <aoliva at redhat dot com>]

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

> On Sun, 9 Mar 2008, Alexandre Oliva wrote:
>> AM33/2.0 and H8SX come to mind, although it's been a while since I
>> dealt with the memory bit-field operations of these two ports to have
>> the details handy.

> Ok, I would expect it a size benefit at most.

I wouldn't think so.  Turning a single hardware-optimized instruction
into a series of load, shift, mask, combine, store is unlikely to
benefit just size.  Especially considering that these optimized
instructions were introduced in revisions of the processor.

And then, I've failed to see a compelling reason to justify such a
change, that would have the effect of disabling this optimization,
even if it was "just" a size optimization.

>> >> > Right.  By means of fixing the BIT_FIELD_REF_UNSIGNED case it is now
>> >> > as specified above.
>> >> 
>> >> This doesn't make the change that went in 

>> > ?

>> ... desirable.

> To recap, what went in is a restriction to constant args 2 and 3 and
> a result TYPE_PRECISION (in case of intergal type) or MODE_PRECISION
> (in other cases) matching to the bit-field size in argument 2.

> The latter change made BIT_FIELD_REF_UNSIGNED redundant and (finally)
> allows for constant folding of BIT_FIELD_REF in fold_ternary.

Good, then you didn't put in the requirement that the first argument
must be a gimple reg, and that its type must be the same as that of
the bit-field.  Those are the changes I object to, but you said they
had gone in.  I couldn't find the patch that did it, but I took your
word for it.  I'm glad it was just a misunderstanding.

As for removing BIT_FIELD_REF_UNSIGNED, I don't have much of a problem
with it.  Using the unsignedness of the BIT_FIELD_REF type works
AFAICT.

However, requiring a perfect match between the result type and the
extracted bit-width is troublesome, because we don't have
language-independent machinery to generate types with arbitrary widths
or even arbitrary precisions.


>> You make for much better optimization, at least with current
>> handling of BIT_FIELD_REF.

>> OTOH, the much constrained version of BIT_FIELD_REF you propose will
>> indeed only generate lots of IL for the most common case of
>> BIT_FIELD_REF.

> It generates much less IL than what the SRA lowering currently does.

The reason SRA generates more IL is *precisely* to get better
optimization.  The back-ends don't handle BIT_FIELD_REFs very well.
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.

Unless you plan on extending the infrastructure that simplifies masks
and shifts such that it deals with BIT_FIELD_REFs and lowers them, at
least when operand 0 is a gimple reg, I'd strongly suggest you to
leave the lowering in BIT_FIELD_REFs in SRA, or perhaps even do that
as part of gimplification.

> This all works fine with the lowering MEM_REF does.  With less IL
> than SRA creates (because of BIT_FIELD_REF).

As long as it doesn't pessimize code (which is what the more IL was
about), I'm game.

>> BIT_FIELD_EXPR appears to be necessary only for SSA gimple registers.
>> For addressable objects, a BIT_FIELD_REF lhs can be much simpler, and
>> it may even generate better code without as much effort.

> BIT_FIELD_REF doesn't play well with our scalar optimizers.

Exactly.  That's why I suggest BIT_FIELD_REFs only for addressable
objects.  SRA will scalarize them if it can; if it can't, scalar
optimizers won't have much to do about them anyway.

> You can't work on registers, as partial writes break SSA form, so
> you need to keep a temporary in memory which is bad.

And then, since this is only useful for gimple registers, and you get
better code if you open-code the bit-field operations for them, I
stand by my claim that it's pointless, and BIT_FIELD_REFs lowered into
open-coded shifting and masking during gimplification would get us
better code.

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