On Wed, 17 Nov 2010 12:16:34 +0200 Ira Rosen <ira.ro...@linaro.org> wrote:
> On 15 November 2010 17:33, Julian Brown <jul...@codesourcery.com> > wrote: > > > On Mon, 15 Nov 2010 10:12:26 +0200 > > Ira Rosen <ira.ro...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
