[RFC] Target-specific limits on vector alignment

[Hans-Peter Nilsson]

> From: Richard Earnshaw <rearnsha@arm.com>
> Date: Mon, 11 Jun 2012 15:16:50 +0200

> The ARM ABI states that vectors larger than 64 bits in size still have
> 64-bit alignment; never-the-less, the HW supports alignment hints of up
> to 128-bits in some cases and will trap in a vector has an alignment
> that less than the hint.  GCC currently hard-codes larger vectors to be
> aligned by the size of the vector, which means that 128-bit vectors are
> marked as being 128-bit aligned.
> 
> The ARM ABI unfortunately does not support generating such alignment for
> parameters passed by value and this can lead to traps at run time.  It
> seems that the best way to solve this problem is to allow the back-end
> to set an upper limit on the alignment permitted for a vector.

Don't you mean lowering the limit on the alignment required and
guaranteed for a vector?  (Or else it sounds like you want to
force attribute-aligned to refuse higher values.)

Wouldn't it be better to make the */*modes.def ADJUST_ALIGNMENT
macro actually work?  Does it work for you?  The epiphany port
tries to do it that way (optionally, not the default AFAICT),
but I bet it's actually unsuccessful.

> I've implemented this as a separate hook, rather than using the existing
> hooks because there's a strong likelihood of breaking some existing ABIs
> if I did it another way.
> 
> There are a couple of tests that will need some re-working before this
> can be committed to deal with the fall-out of making this change; I'll
> prepare those changes if this patch is deemed generally acceptable.

It'd be nice to have non-naturally-aligned vectors working in
general.

I have a MIPS COP2 128-bit-SIMD implementation for 32-bit MIPS,
which means 64-bit stack-alignment and memory loads and stores
are in 64-bit parts.  So, I've chosen to not require any larger
alignment to keep ABI compatibility (vectors aren't passed in
registers; core use is intra-function anyway).  This mostly
works, but there's pushback from gcc (at least in 4.3): trying
to adjust vector-type-alignment by e.g. "ADJUST_ALIGNMENT (V4SI,
8);" in mips-modes.def has no effect; I had to do it in
mips_builtin_vector_type, which might be brittle or just working
by chance.  Then there's the tree-vectorizer, which for some
optimizations wants to assume natural alignment when doing
"floor alignment".  I couldn't define a usable
"vec_realign_load_<mode>" (undocumented) as it assumes that the
low vector-size bits of an address will exactly correspond to
misalignment when masking off and applying to a vector.  And,
you may have to conditionalize some vectorizer tests with the
effective-target unaligned_stack.

Just preparing you for the fall-out. :]

brgds, H-P