On Mon, 15 Nov 2010 10:12:26 +0200 Ira Rosen ira.rosen@linaro.org wrote:
Hi Julian,
On 12 November 2010 17:49, Julian Brown julian@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.
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.
So, anyway, back to the patch in question. The choices are, I think:
- 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.
- 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.
Thanks,
Julian