On Mon, Jun 8, 2015 at 4:19 PM, Andrew Pinski <pins...@gmail.com> wrote: > 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.
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 > > 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
