This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal for merging scalar-storage-order branch into mainline

On Mon, Jun 8, 2015 at 4:19 PM, Andrew Pinski <> wrote:
> On Mon, Jun 8, 2015 at 4:05 PM, Eric Botcazou <> 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:
>> 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.

Oh and I see a case where we want to remove byteswaps at IPA level. If
we can see the variable value does not escape.


> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]