This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode
- From: Paul Brook <paul at codesourcery dot com>
- To: Julian Brown <julian at codesourcery dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>, Ramana Radhakrishnan <ramrad01 at arm dot com>, Richard Earnshaw <rearnsha at arm dot com>
- Date: Mon, 4 Mar 2013 23:47:22 +0000
- Subject: Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode
- References: <20130227172947.31fa279c@octopus> <20130304152922.25c9cfba@octopus> <20130304172440.68e49f14@octopus>
> 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.
There's still the possibility of making gcc "generic" vector types different
from the ABI specified types[1], but that feels like it's probably a really
bad idea.
Having a distinct set of types just for the vectorizer may be a more viable
option. IIRC the type selection hooks are more flexible than when we first
looked at this problem.
Paul
[1] e.g. int gcc __attribute__((vector_size(8))); v.s. int32x2_t eabi;