On Mon, Jun 8, 2015 at 10:05 AM, Eric Botcazou <ebotca...@adacore.com> wrote: > Hi, > > I'd like to propose merging the scalar-storage-order branch that I have been > maintaining for a couple of years into mainline. Original announcement at: > https://gcc.gnu.org/ml/gcc/2013-05/msg00249.html > > It implements an attribute (C/C++/Ada only) that makes it possible to specify > the storage order (aka endianness) of scalar components of aggregate types; > for example, you can declare a structure with big-endian SSO containing only > scalar fields and it will have the same representation in memory on x86 and on > PowerPC or SPARC. Nesting of structures with different SSO is also supported. > > The feature has been present in the GCC-based compilers released by AdaCore > for a few more years and the users generally find it very useful (some of them > even asked why we hadn't implemented it earlier). > > As the initial plan was to maintain it in AdaCore's tree until it reached a > sufficient level of maturity, the implementation was designed to be relatively > light and maintainable, with the following basic principle: specifying the > same SSO as that of the target machine is equivalent to specifying no SSO. > This principle holds for the entire implementation, which means that only the > reverse SSO is tracked, which in turn means that the target machine must be > uniform wrt endianness (e.g. PDP endianness is not supported). > > Only GENERIC is extended (one flag on aggregate types and one flag on some > _REF nodes) by using the following guidelines: > > 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. > > GIMPLE proper and RTL are not changed. The byte swapping operations are made > explicit during RTL expansion and use the bswap patterns of the target machine > if present.
What's the reason to not expose the byte swapping operations earlier, like on GIMPLE? (or even on GENERIC?) > The bulk of the implementation is in the FEs (sanity checks, propagation, etc) What frontends are affected? Thanks, Richard. > and the RTL expander (+ varasm.c for aggregate literals). RTL optimizers are > not changed. GIMPLE optimizers are minimally changed: they can either punt if > they see _REF nodes with reverse SSO or choose to locally maintain the SSO. > > Again this was designed with maintainability and simplicity in mind, so no > attempt was made at generating optimal code. At the same time the support is > transparent for most GIMPLE optimizers so there is no definitive blocker > towards this goal if it is deemed worth pursuing for this kind of feature. > > -- > Eric Botcazou
