> From: Richard Earnshaw <rearn...@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
