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. > 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 optimization. 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 http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
