On 13/10/11 15:56, Joseph S. Myers wrote: > On Thu, 13 Oct 2011, Richard Earnshaw wrote: > >> 2) Change the compiler to make initializers of vectors assign elements >> of initializers to consecutive lanes in a vector, rather than the >> current behaviour of 'casting' an array of elements to a vector. >> >> While the second would be my preferred change, I suspect it's too hard >> to fix, and may well cause code written for other targets to break on >> big-endian (altivec for example). > > Indeed, vector initializers are part of the target-independent GNU C > language and have target-independent semantics that the elements go in > memory order, corresponding to the target-independent semantics of lane > numbers where they appear in GENERIC, GIMPLE and (non-UNSPEC) RTL and any > target-independent built-in functions that use such numbers. (The issue > here being, as you saw, that the lane numbers used in ARM-specific NEON > intrinsics are for big-endian not the same as those used in > target-independent features of GNU C and target-independent internal > representations in GCC - hence various code to translate them between the > two conventions when processing intrinsics into non-UNSPEC RTL, and to > translate back when generating assembly instructions that encode lane > numbers with the ARM conventions, as expounded at greater length at > <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00409.html>.) >
This is all rather horrible, and leads to THREE different layouts for a 128-bit vector for big-endian Neon. GCC format 'VLD1.n' format 'ABI' format GCC format and 'ABI' format differ in that the 64-bit words of the 128-bit vector are swapped. All this and they are all expected to share a single machine mode. Furthermore, the definitions in GCC are broken, in that the types defined in arm_neon.h (eg int8x16_t) are supposed to be ABI format, not GCC format. Eukkkkkk! :-( R.
