This is the mail archive of the
mailing list for the GCC project.
Re: Proposal for merging scalar-storage-order branch into mainline
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 8 Jun 2015 10:34:40 +0200
- Subject: Re: Proposal for merging scalar-storage-order branch into mainline
- Authentication-results: sourceware.org; auth=none
- References: <2354857 dot 0uXrE6NL1R at polaris>
On Mon, Jun 8, 2015 at 10:05 AM, Eric Botcazou <email@example.com> wrote:
> 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
> 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?
> 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