Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Mar 5, 2013 at 12:47 AM, Paul Brook <paul@codesourcery.com> wrote:
>> I somehow missed the "Appendix A: Support for Advanced SIMD Extensions"
>> in the AAPCS document (it's not in the TOC!). It looks like the
>> builtin vector types are indeed defined to be stored in memory in
>> vldm/vstm order -- I think that means we're back to square one.
>
> There's still the possibility of making gcc "generic" vector types different
> from the ABI specified types[1], but that feels like it's probably a really
> bad idea.
>
> Having a distinct set of types just for the vectorizer may be a more viable
> option. IIRC the type selection hooks are more flexible than when we first
> looked at this problem.
>
> Paul
>
> [1] e.g. int gcc __attribute__((vector_size(8)));  v.s. int32x2_t eabi;

I think int32x2_t should not be a GCC vector type (thus not have a vector mode).
The ABI specified types should map to an integer mode of the right size
instead.  The vectorizer would then still use internal GCC vector types
and modes and the backend needs to provide instruction patterns that
do the right thing with the element ordering the vectorizer expects.

How are the int32x2_t types used?  I suppose they are arguments to
the intrinsics.  Which means that for _most_ operations element order
does not matter, thus a plus32x2 (int32x2_t x, int32x2_t y) can simply
use the equivalent of return (int32x2_t)((gcc_int32x2_t)x + (gcc_int32x2_t)y).
In intrinsics where order matters you'd insert appropriate __builtin_shuffle()s.

Oh, of course do the above only for big-endian mode ...

The other way around, mapping intrinsics and ABI vectors to vector modes
will have issues ... you'd have to guard all optab queries in the middle-end
to fail for arm big-endian as they expect instruction patterns that deal with
the GCC vector ordering.

Thus: model the backend after GCCs expectations and "fixup" the rest
by fixing the ABI types and intrinsics.

Richard.