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: reverse bitfield patch

On Fri, Oct 5, 2012 at 8:15 PM, DJ Delorie <> wrote:
>> Why do you need to change varasm.c at all?  The hunks seem to be
>> completely separate of the attribute.
> Because static constructors have fields in the original order, not the
> reversed order.  Otherwise code like this is miscompiled:

Err - the struct also has fields in the original order - only the bit positions
of the fields are different because of the layouting option.

> struct foo a = { 1, 2, 3 };
> because the 1, 2, 3 are in the C layout order, but the underlying data
> needs to be stored in the reversed order.

And you expect no other code looks at fields of a structure and its
initializer?  It's bad to keep this not in-sync.  Thus I don't think it's
viable to re-order fields just because bit allocation is reversed.

>> which will severely pessimize bitfield accesses to structs with the
>> bitfield-order attribute.
> The typical use-case for this feature is memory-mapped hardware, where
> pessimum access is preferred anyway.

I doubt that, looking at constraints for strict volatile bitfields.

>> so you are supporting this as #pragma.  Which ends up tacking
>> bit_order to each type.  Rather than this, why not operate similar
>> to the packed pragma, thus, adjust a global variable in
>> stor-layout.c.
> Because when I first proposed this feature, I was told to do it this
> way.
>> I don't see a value in attaching 'native' or 'msb'/'lsb' if it is
>> equal to 'native'.  You un-necessarily pessimize code generation (is
>> different code even desired for a "no-op" bit_order attribute?).
> If the attribute corresponds to the native mode, it should be a no-op.
> The pessimizing only happens when the fields are actually in reverse
> order.

No, because you check for the attribute presence.

>> So no, I don't like this post-process layouting thing.  It's a
>> layouting mode so it should have effects at bitfield layout time.
> The actual reversal happens in stor-layout.c.  Everything else is
> there to compensate for a possible non-linear layout.

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