This is the mail archive of the gcc@gcc.gnu.org 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: [announce] New scalar-storage-order branch in GCC repository


> Can you post an overview of the implementation?  Naively I'd have extended
> GENERIC only and lowered all affected scalar accesses to
> __builtin_bswapN (<load>) and <store> = __builtin_bswapN (...) and rely
> on RTL expansion / combine to generate instructions for a target that
> supports such byte-swapping loads/stores in HW.

That's the design, yes, although we don't explicitly lower to __builtin_bswap,
except for very specific cases where the FE does some low-level fiddling, in 
which cases it directly generates a call to the Ada wrapper of the builtin.

Only GENERIC is indeed extended (one flag on aggregate types and one flag on 
some _REF nodes) by using the following guidelines (quoting tree.h):

   The overall strategy is to preserve the invariant that every scalar in
   memory is associated with a single storage order, i.e. all accesses to
   this scalar are done with the same storage order.  This invariant makes
   it possible to factor out the storage order in most transformations, as
   only the address and/or the value (in target order) matter for them.
   But, of course, the storage order must be preserved when the accesses
   themselves are rewritten or transformed.

Then the byte swapping operations are made explicit during RTL expansion and, 
of course, you'd better have bswap<mode>2 patterns defined in your back-end.

The storage order is a property attached to aggregate types, but nesting is 
supported as long as it can be defined consistently (i.e. the storage order 
only changes at byte boundaries), although you may need FE assistance here.

The only (big) limitation is thay you cannot take the address of an individual 
field in these aggregate types, but in Ada it's not a problem since it's the 
default for any field in any aggregate type.

-- 
Eric Botcazou


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