On Mar 9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Sun, 9 Mar 2008, Alexandre Oliva wrote: >> 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? AM33/2.0 and H8SX come to mind, although it's been a while since I dealt with the memory bit-field operations of these two ports to have the details handy. >> > 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 > ? ... desirable. >> > 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. You make for much better optimization, at least with current handling of BIT_FIELD_REF. OTOH, the much constrained version of BIT_FIELD_REF you propose will indeed only generate lots of IL for the most common case of BIT_FIELD_REF. >> 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. What do you mean, won't work? You get a read followed by a write, even if for a wider unit of the object, which AFAIK is legitimate implementation-defined behavior for volatile bit-fields. > Why do you think you cannot create temporaries for memory refs? You > did the same with SRA. You can. It's just not as easy. You see the amount of IL for replacing stuff. And then, SRA does not really create temporaries for MEMs that remain as the primary copy of an object, which is the case I'm really talking about. The temporaries created by SRA mostly replace the corresponding MEMs. Besides, in SRA, for example, we'll often create a temporary that holds multiple bit-fields that didn't make sense to scalarize on their own. If I'd worked harder on it, they wouldn't even have to be contiguous, as long as they were in the same word. BIT_FIELD_REF couldn't represent this, though. >> 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. BIT_FIELD_EXPR appears to be necessary only for SSA gimple registers. For addressable objects, a BIT_FIELD_REF lhs can be much simpler, and it may even generate better code without as much effort. -- 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}
