On Mon, Jun 8, 2015 at 4:05 PM, 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.
The only problem I see with this implementation is that the RTL level optimizers are not always up to removing the byteswaps. GCSE is very weak on the RTL level compared to PRE on the gimple level. Thanks, Andrew Pinski > > The bulk of the implementation is in the FEs (sanity checks, propagation, etc) > 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
