On Sun, 9 Mar 2008, Alexandre Oliva wrote: > On Mar 8, 2008, Richard Guenther <[EMAIL PROTECTED]> 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.
