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>.) -- Joseph S. Myers jos...@codesourcery.com
