This is the mail archive of the 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 Mar  9, 2008, Richard Guenther <> 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

>> 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
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

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