[PATCH, WIP] NEON quadword vectors in big-endian mode (#10061, #7306)

Julian Brown julian at codesourcery.com
Mon Nov 15 15:33:35 UTC 2010

On Mon, 15 Nov 2010 10:12:26 +0200
Ira Rosen <ira.rosen at linaro.org> wrote:

> Hi Julian,
> On 12 November 2010 17:49, Julian Brown <julian at 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

> >
> > 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.



More information about the linaro-toolchain mailing list