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: Constrain valid arguments to BIT_FIELD_REF

On Mar  8, 2008, Richard Guenther <> wrote:

> On Sat, 8 Mar 2008, Alexandre Oliva wrote:
>> > the object referenced is of integral type

>> This would break the use of SRA to extract sub-objects of non-integral
>> type.  IIRC Ada does such things.

> No frontend generates BIT_FIELD_REF.  But yes, SRA does with
> structures as base object.

I meant Ada can have non-integral members that are do not occupy an
integral number of bytes.

> We don't yet enforce this, MEM_REF will enforce BIT_FIELD_REF
> operates on registers only.

Do you have any plans to recover the performance loss for machines
that have bit-field instructions that operate directly in memory?
Especially for writes, I don't see how this is going to work.

>> > the result type is of the same type as the operand zero type
>> Err, this doesn't make much sense to me.  Consider:

> 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 

> The least conversion is removed.  You can look at the MEM_REF branch
> and see that the load from memory is done with a MEM_REF expression
> from the register result the bits are extracted with BIT_FIELD_REF.

Extracting (or replacing) bits from registers of integral type with
BIT_FIELD_REF is not very useful.  You're better off expanding the
BIT_FIELD_REF into mask and shift operations to get better

It is for memory access that BIT_FIELD_REF makes the most sense,
because you can't create temporaries or duplicates for memory refs as
easily, especially when memory is volatile.

This new definition of BIT_FIELD_REF you came up with appears to be
redundant and useless to me.  All the interesting uses are ruled out,
and only uninteresting (and harmful) uses remain.  Might as well just
get rid of it, and later on realize it is needed for the interesting
cases and re-introduce it with the previous semantics.

Unless MEM_REF can be used to refer to arbitrary bit ranges.  In this
case, BIT_FIELD_REF is completely obviated.

Alexandre Oliva
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

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