This is the mail archive of the
mailing list for the GCC project.
Re: Constrain valid arguments to BIT_FIELD_REF
On Sun, 9 Mar 2008, Alexandre Oliva wrote:
> On Mar 8, 2008, Richard Guenther <email@example.com> 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.
After layouting the type?
> > 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.
Do you have an example target in mind?
> >> > 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
You only generate lots of IL this way.
> 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.
Volatile bit-field ref stores won't work on most targets anyway,
so this is a non-issue. Why do you think you cannot create temporaries
for memory refs? You did the same with SRA.
> 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.
See above, it is mainly to ease combining with BIT_FIELD_EXPR.
> Unless MEM_REF can be used to refer to arbitrary bit ranges. In this
> case, BIT_FIELD_REF is completely obviated.
MEM_REF can only access byte aligned and sized storage.