On Wed, 17 Nov 2010 12:16:34 +0200 Ira Rosen ira.rosen@linaro.org wrote:
On 15 November 2010 17:33, Julian Brown julian@codesourcery.com wrote:
On Mon, 15 Nov 2010 10:12:26 +0200 Ira Rosen ira.rosen@linaro.org wrote:
Do you think now that the changes in GIMPLE and RTL (a function attached to each vector) are unnecessary?
Yes, I now think they're unnecessary, at least in theory. In practice if patterns are shared between the vectorizer and generic vector machinery then they may need some attention -- e.g. we wouldn't want to use vec_shl_<mode>/vec_shr_<mode> still for big-endian generic vectors, since they'd permute the result. Maybe we could use a target macro named something like *_GENERIC_VECTORS_IN_ARRAY_ORDER to control whether such (element-ordering dependent) patterns could be used for generic vectors.
What do you mean by generic vectors? I am used to call generic vectors to , for example, vector of 4 chars in 32-bit int, when there is no vector unit, but I guess you are talking about intrinsics.
I mean the user-visible support for directly writing cross-platform vector code, as described in:
http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Vector-Extensions.html
I.e., declaring a type using the vector_size attribute, then using regular arithmetic operators on it (some work is being done at present to extend the number of available operations a little). AFAIK use of this feature isn't especially widespread, nor particularly well-specified: I mainly brought it up to mention the possibility of inadvertently mixing "generic vector" dereferences with NEON intrinsics.
We'd need to figure out what the RTL for such loads/stores should look like, and whether it can represent alignment constraints, or strides, or loads/stores of multiple vector registers simulateously. Getting it right might be a bit awkward, especially if we want to consider a scope wider than just NEON, i.e. other vector architectures also.
I think we need to somehow enhance MEM_REF, or maybe generate a MEM_REF for the first vector and a builtin after it.
Yeah, keeping these things looking like memory references to most of the compiler seems like a good plan.
I slightly prefer the first one, it's kind of an incremental solution.
OK. I'll try to figure out the wrinkles.
I hope it's not too much work, because otherwise there is no point, since we are going to remove it later anyway.
Shouldn't be more than 1-2 days, but I've been distracted by other bugs...
Julian