Proposal for merging scalar-storage-order branch into mainline
Mon Jun 8 08:06:00 GMT 2015
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:
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
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.
More information about the Gcc