Proposal for merging scalar-storage-order branch into mainline

[Eric Botcazou <ebotcazou at adacore dot com>]

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 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