This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [announce] New scalar-storage-order branch in GCC repository
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 27 May 2013 18:24:02 +0200
- Subject: Re: [announce] New scalar-storage-order branch in GCC repository
- References: <27956919 dot dmEeeluqpD at polaris> <CAFiYyc1DYL0VFKTC-F-_wnkaF8NiNiNghmM_2Eezk-R30xuAwQ at mail dot gmail dot com>
> 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