On Thu, Jul 9, 2020 at 9:29 AM Eric Botcazou <botca...@adacore.com> wrote: > > > 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.
Hmm, I'd probably avoid to assign a storage order to rvalues (SSA names and pseudos) and simply go with a storage order on lvalues. That means SRA can only scalarize when all actual accesses have the same storage order and "full" scalarization (scalarization of portions where no accesses are observed) can be only done when its materialized back to memory. So I don't see where the need arises to tag pointers apart from on the frontend side which of course needs to tag dereferences of pointers appropriately for the middle-end. In particular memcpy() behaves storage-order agnostic so it shouldn't care. I don't see how aliases or storage order "punning" become a problem then. It's no different from aliasing int and float accesses? As of treating it like address-spaces, yes - it's basically like that at the moment but with more implementation restrictions. Richard. > -- > Eric Botcazou
