This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode


On Mon, 4 Mar 2013 15:29:22 +0000
Julian Brown <julian@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


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