> OK with me. Thanks.
> I still believe we could handle reverse storage order more "optimistically" > (without all the current usage restrictions). We seem to have no problems > with address-spaces in this area for example (their problematic cases are > of course slightly different). The fundamental restriction of the implementation is that we don't assign a storage order to the scalar rvalues themselves, i.e. there is only one kind of scalar rvalues and they are represented in target order. Only scalar lvalues can have a storage order. This one cannot reasonably be relaxed I think. >From there, you have secondary restrictions related to aliasing: - are pointers to scalar values stored in reverse order allowed? Currently they are not and the compiler issues an error if you try to make one. This one could probably be relaxed by adding a "reverse" flag to pointers and the analogy with address-spaces would be exact (as a matter of fact, the latest UltraSPARC specifications introduced an Address Space Identifier for little- endian data, so these pointers could be implemented in hardware for them). - is storage order toggling by means of aliasing supported? Currently it is not and this is documented as such. This one looks hard to relax because this would be essentially equivalent to relaxing the fundamenal restriction: if you apply SRA to such a case, either materially or symbolically through VN, you will need to effectively assign a storage order to scalar rvalues internally. -- Eric Botcazou
