This is the mail archive of the gcc@gcc.gnu.org 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 Sun, 9 Mar 2008, Alexandre Oliva wrote:

> On Mar  8, 2008, Richard Guenther <rguenther@suse.de> 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
> optimization.

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.

Richard.


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