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: > > > Hi Julian, > > > > On 12 November 2010 17:49, Julian Brown <jul...@codesourcery.com> > > wrote: > > > ... > > > The important observation is that vectors from case 1 and from > > > cases 2/3 never interact: it's quite safe for them to use different > > > element orderings, without extensive changes to GCC infrastructure > > > (i.e., multiple internal representations). I don't think I quite > > > realised this previously. > > > > > > > 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. > > > From the vectorizer point of view, target hooks look like the easiest > > solution (yet ugly). I am trying to think about something else, but > > nothing really makes sense. > > Yeah, I was thinking something along those lines. So we might have > TARGET_VECTORIZER_ARRAY_LOADS or something to use new "standard names" > for loading/storing vectors in array order, rather than using plain > (mem (foo)). > > 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. > > > > > > > So, anyway, back to the patch in question. The choices are, I think: > > > > > > 1. Apply as-is (after I've ironed out the wrinkles), and then > > > remove the "ugly" bits at a later point when vectorizer "array > > > load/store" support is implemented. > > > > > > 2. Apply a version which simply disables all the troublesome > > > patterns until the same support appears. > > > > > > > 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. Thanks, Ira > > Thanks, > > Julian >
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
