On Mon, 4 Mar 2013 15:29:22 +0000 Julian Brown <jul...@codesourcery.com> wrote:
> > Remember that it's not just function arguments, it's any interface > > shared between functions. i.e. including structures and global > > variables. > > Ugh, I hadn't considered structures or global variables :-/. If we > decide they have to use the containerized format also, then we lose a > lot of the supposed advantage of using array-format vectors > "everywhere" (apart from at procedure call boundaries), for instance > if we want code with a global variable like: > [...] > Skimming the AAPCS, I'm not sure it actually specifies anything about > the layout of global variables which may be shared between functions > (it'd make sense to do so -- maybe it's elsewhere in the EABI > documents). Aggregates passed by value could also be > marshalled/unmarshalled like vectors, though that starts to sound much > less tractable than dealing with vectors alone. I somehow missed the "Appendix A: Support for Advanced SIMD Extensions" in the AAPCS document (it's not in the TOC!). It looks like the builtin vector types are indeed defined to be stored in memory in vldm/vstm order -- I think that means we're back to square one. So: thoughts on disabling vectorization altogether in big-endian mode? Julian
